Re: qwx0 / QCNFA765 Does 802.11g Only

2024-03-04 Thread Stefan Sperling
On Sun, Mar 03, 2024 at 05:02:13PM +0100, Omar Polo wrote:
> Hello,
> 
> On 2024/03/03 15:07:34 +0100, 20 100  wrote:
> > Hello Stefan,
> > 
> > First of all many thanks for your work around qwx.
> > 
> > Here after some observations on my T14s regarding qwx.
> > 
> > My OpnBSD current setup is not my daily machine, but sounds that this
> > driver is quite stable ;).
> > 
> > My main message is that when running Apline Linux (in dual boot), I've got
> > different values performance values:
> > - Linux: 109Mbps download and 12Mbps upload (via testmy.net)
> > - Openbsd: 20Mbps download, 1.9Mbps upload (via testmy.net)
> 
> Probably because qwx(4) as of now only does 802.11g, not 11n or 11ac.

Yes, that is the reason.



Re: qwx0 / QCNFA765 Does 802.11g Only

2024-03-02 Thread Stefan Sperling
On Sat, Mar 02, 2024 at 10:54:34PM -0500, Philippe Meunier wrote:
> >Can you please show a beacon of this AP?
> >
> >One line from tcpdump this command while trying to associate to the AP should
> >suffice:
> >
> >  tcdump -n -i qwx0 -y IEEE802_11_RADIO -s 1500 -v wlan host 
> > 20:c0:47:bb:bc:4c
> >
> >I am looking for the field which lists the supported rates:
> >
> >   ... rates 6M* 9M 12M* 18M 24M* 36M 48M 54M, ...
> >
> 
> Before, during, and after:
 
>  rates 6M* 9M 12M* 18M 24M* 36M 48M 54M,

That looks fine. The AP can't be rejecting the client based on this
standard basic rate set. So the rejection is likely indeed a way of
saying "go away, you do not support 11n/11ac".



Re: qwx0 / QCNFA765 Does 802.11g Only

2024-03-01 Thread Stefan Sperling
On Fri, Mar 01, 2024 at 07:14:17PM -0500, Philippe Meunier wrote:
> Mar  1 18:22:19 t14 /bsd: qwx0: sending assoc_req to 20:c0:47:bb:bc:4c on 
> channel 40 mode 11a
> Mar  1 18:22:19 t14 /bsd: qwx0: association failed (status 18) for 
> 20:c0:47:bb:bc:4c
> Mar  1 18:22:23 t14 /bsd: qwx0: association timed out for 20:c0:47:bb:bc:4c

Apparently the AP refused association because the client's request does
not meet the basic rate set requirements (status 18).

qwx works fine on my 11ac AP in 11a mode. This driver does not yet
support 11n/11ac modes, and adding such support will require a big
chunk of further development time, it won't be ready for 7.5.

Does your AP have support for "legacy 11a/b/g" clients disabled somehow?
Some APs advertise such options for performance in their config and may
need to be disabled to make it work.

Can you please show a beacon of this AP?

One line from tcpdump this command while trying to associate to the AP should
suffice:

  tcdump -n -i qwx0 -y IEEE802_11_RADIO -s 1500 -v wlan host 20:c0:47:bb:bc:4c

I am looking for the field which lists the supported rates:

   ... rates 6M* 9M 12M* 18M 24M* 36M 48M 54M, ...



Re: qwx0: failed to send/start with QCNFA765

2024-02-23 Thread Stefan Sperling
On Fri, Feb 23, 2024 at 11:58:51AM +0100, Marco van Hulten wrote:
> Today, after installing the latest snapshot, I do not get this error
> anymore.  Does it contain the patch?

Yes, it should.
The latest snap's build date is newer than my commit from last night.

> Wi-Fi to normal access points is working fine.  Still a problem with
> eduroam, but I think that should be unrelated to qwx(4).

Perhaps, I wouldn't know. I don't have any way to test WPA Enterprise.



Re: qwx0: failed to send/start with QCNFA765

2024-02-22 Thread Stefan Sperling
On Thu, Feb 22, 2024 at 03:28:42PM +0100, Marco van Hulten wrote:
> On Thu, 22 Feb 2024 13:29:27 +0100 Stefan Sperling wrote:
> > Can you reproduce this on non-WPA-Enterprise networks,
> > i.e. without eduraom / wpaakms 802.1x?
> 
> Did not succeed in reproducing so far.

I figured out the scan command error, details and patch below.

The good news is that this is just a cosmetic issue.
Let me know if you still see any issues with the patch applied.

> Additional dmesg output that seems to be new:
> 
> qwx0: missed beacon threshold set to 30 beacons, beacon interval is 100 TU
> qwx0: failed to enqueue rx buf: 28
> qwx_ce_recv_process_cb: failed to post rx buf to pipe: 2 err: 28

The above is a known issue I still need to investigate.
I suspect it is harmless.

Now, regarding your scan command failures:

An important detail is that ifconfig will make multiple calls into
the kernel while reconfiguring the interface:

ifconfig qwx0 nwid eduroam wpa wpaakms 802.1x up

This command enters the driver in the kernel 4 times in a row:

nwid eduroam# 1) set network ID
wpa # 2) enable WPA
wpaakms 802.1x  # 3) enable WPA Enterprise
up  # 4) set UP flag

Every time the driver is entered, a configuration change is flagged
(by signalling error ENETRESET internally) which causes the driver
to stop and restart the interface to let the configuration change take
effect. Provided the interface is already marked UP, the final step
of restarting a wifi device is to begin a scan for APs.

This scan runs in a separate background thread in the kernel and the
ifconfig process will continue running "in parallel" to the scan.
ifonfig will more or less immediately enter the kernel again to
apply the next configuration item (e.g. in step 2 to enable WPA).

Now the driver wants to stop the interface again, but the scan thread
is still active!
We don't want the device to see a confusing mix of commands coming from
multiple threads, so the driver needs to wait for the scan thread to
finish before it can proceed to stop and restart the device again.
The ifconfig driver thread sets a global "please stop" flag and waits...

Before the scan thread sends its scan command it will check the "please stop"
flag. When it is set, the Linux code we inherited returns ESHUTDOWN, which
is error number 58. This matches the error you are seeing:

  qwx0: failed to start hw scan: 58

So this is not an actual error condition, it is expected behaviour.
ESHUTDOWN will cause the scan thread to stop what is it doing and
allow the ifconfig driver thread to take back control of the hardware.

The patch below should avoid printing a warning about this for all
WMI commands, including your case, but handling other potential
cases as well.

---
 make qwx(4) ignore ESHUTDOWN while printing errors to dmesg
 
 ESHUTDOWN is an expected thread-synchronization condition which
 can be triggered via ifconfig commands. Don't warn about this.
 
 Reported by Marco van Hulten on misc@
 
diff 11a0e80d7bc8830d3a9189682bad3c13b0eeb2cb 
9d7e156a181573d2b75a72c9297a5ec5796865f7
commit - 11a0e80d7bc8830d3a9189682bad3c13b0eeb2cb
commit + 9d7e156a181573d2b75a72c9297a5ec5796865f7
blob - 43753d3d31405116391a7f706fb0735162b062b5
blob + f0ad77d417bb8774b7de90c543705bd9bbec57a9
--- sys/dev/ic/qwx.c
+++ sys/dev/ic/qwx.c
@@ -17232,8 +17232,10 @@ qwx_wmi_pdev_set_param(struct qwx_softc *sc, uint32_t 
 
ret = qwx_wmi_cmd_send(wmi, m, WMI_PDEV_SET_PARAM_CMDID);
if (ret) {
-   printf("%s: failed to send WMI_PDEV_SET_PARAM cmd\n",
-   sc->sc_dev.dv_xname);
+   if (ret != ESHUTDOWN) {
+   printf("%s: failed to send WMI_PDEV_SET_PARAM cmd\n",
+   sc->sc_dev.dv_xname);
+   }
m_freem(m);
return ret;
}
@@ -17268,8 +17270,10 @@ qwx_wmi_pdev_lro_cfg(struct qwx_softc *sc, uint8_t pde
 
ret = qwx_wmi_cmd_send(wmi, m, WMI_LRO_CONFIG_CMDID);
if (ret) {
-   printf("%s: failed to send lro cfg req wmi cmd\n",
-   sc->sc_dev.dv_xname);
+   if (ret != ESHUTDOWN) {
+   printf("%s: failed to send lro cfg req wmi cmd\n",
+   sc->sc_dev.dv_xname);
+   }
m_freem(m);
return ret;
}
@@ -17303,8 +17307,10 @@ qwx_wmi_pdev_set_ps_mode(struct qwx_softc *sc, int vde
 
ret = qwx_wmi_cmd_send(wmi, m, WMI_STA_POWERSAVE_MODE_CMDID);
if (ret) {
-   printf("%s: failed to send WMI_PDEV_SET_PARAM cmd\n",
-   sc->sc_dev.dv_xname);
+   if (ret != ESHUTDOWN) {
+   printf("%s: failed to send WMI_PDEV_SET_

Re: qwx0: failed to send/start with QCNFA765

2024-02-22 Thread Stefan Sperling
On Thu, Feb 22, 2024 at 11:35:35AM +0100, Marco van Hulten wrote:
> Hello,
> 
> The Qualcomm QCNFA765 (support recently added) in my ThinkPad P14s
> worked for some time, but now it mostly does not and I get these kernel
> messages:
> 
>   qwx0: failed to send WMI_START_SCAN_CMDID
>   qwx0: failed to start hw scan: 58
> 
> This happens when I run this command:
> 
>   ifconfig qwx0 nwid eduroam wpa wpaakms 802.1x up
> 
> dmesg is attached.  Is this a bug or am I doing something wrong?
> 
> Similar, when I first scan and then try to join an open network,
> following qwx(4),
> 
>   qwx0: failed to send WMI_11D_SCAN_START_CMDID: 58
>   qwx0: failed to start 11d scan; vdev: 0 ret: 58
>   qwx0: failed to send WMI_START_SCAN_CMDID
>   qwx0: failed to start hw scan: 58
> 
> Sometimes it works again; I cannot put my finger what triggers the
> problem.

Please show a full trace that appears after you run 'ifconfig qwx0 debug'.

Can you reproduce this on non-WPA-Enterprise networks,
i.e. without eduraom / wpaakms 802.1x?



Re: Unable to connect to WiFi on new OpenBSD installation

2024-02-03 Thread Stefan Sperling
On Sat, Feb 03, 2024 at 10:57:37AM +0100, Stefan Sperling wrote:
> On Sat, Feb 03, 2024 at 07:26:33AM +0100, Sadeep Madurange wrote:
> > Hello,
> > 
> > I installed OpenBSD on a T490. I can't connect to WiFi. I'm not sure if 
> > it's because the device is not supported. In the dmesg I see the following 
> > line:
> > 
> > "Intel Wi-Fi 6 AX201" rev 0x00 at pci0 dev 20 function 3 not configured
> > 
> > I ran fw_update, and I can see the iwx-* files under /etc/firmware. I'm not 
> > sure what to do next. The installed OpenBSD version (from uname -a) is 7.4 
> > GENERIC.MP#2 i386.
> > 
> > 
> 
> Please try a -current snapshot.

Oh wait, i386? You need amd64.



Re: Unable to connect to WiFi on new OpenBSD installation

2024-02-03 Thread Stefan Sperling
On Sat, Feb 03, 2024 at 07:26:33AM +0100, Sadeep Madurange wrote:
> Hello,
> 
> I installed OpenBSD on a T490. I can't connect to WiFi. I'm not sure if it's 
> because the device is not supported. In the dmesg I see the following line:
> 
> "Intel Wi-Fi 6 AX201" rev 0x00 at pci0 dev 20 function 3 not configured
> 
> I ran fw_update, and I can see the iwx-* files under /etc/firmware. I'm not 
> sure what to do next. The installed OpenBSD version (from uname -a) is 7.4 
> GENERIC.MP#2 i386.
> 
> 

Please try a -current snapshot.



Re: Weird network performance with iwn(4)

2024-01-09 Thread Stefan Sperling
On Thu, Dec 21, 2023 at 09:23:42AM +0100, Stefan Sperling wrote:
> could you send me a pcap of 5GHz beacons from this AP?

Nothing in the beacon you sent off-list stands out.
I don't see a reason why things wouldn't work as they should.

The AP is set to country 'US' -- if this is incorrect then try
setting the contry code to the actual country the AP is located in.
The AP uses an 80MHz channel config in the first channel segment (with
center channel 42), which should work anywhere in the world. So there
is no reason to believe that the country code would cause issues.
However, Intel firmware uses black-box regulatory heuristics which the
driver has little control over. With some luck a wrong country code is
the reason for your trouble.

Otherwise, I don't know. You could try turning configurable features
of the AP off one-by-one to see if a factor which triggers the issue
can be identified that way.



Re: Cannot PXE Boot PC Engines APU.1D4

2024-01-01 Thread Stefan Sperling
On Mon, Jan 01, 2024 at 01:56:28AM +, Kenneth Hendrickson wrote:
> Cannot PXE Boot PC Engines APU.1D4
> 
> Have tried both i386 and amd64.
> Verified that my tftpd server is working.
> 
> This used to work.  Now fails.
> Hardware is about 10 years old.
> Do I need new hardware??
> 
> What is recommended?
> Need minimum of 3 ethernet ports.
> 
> Thanks in advance.
> 
> 

Booting 7.4 or -current kernels with an old pxeboot binary won't work.
Make sure that both the kernel image and pxeboot originate from the
7.4 release or -current.



Re: Weird network performance with iwn(4)

2023-12-21 Thread Stefan Sperling
On Wed, Dec 20, 2023 at 07:54:47PM +, Lévai, Dániel wrote:
> Danel Levai wrote:
> > Stuart Henderson wrote:
> > > I checked for openwrt support but your AP has a relatively uncommon
> > > Realtek SoC and it seems fairly unlikely to happen so you're probably
> > > stuck with the vendor firmware.
> > >
> > > Maybe try forcing "mode 11n" or "mode 11g" with ifconfig and see if
> > > that's any better.
> >
> > Interestingly enough, "mode 11g" won't join the AP. 11n works and it's a 
> > steady
> > 300KByte/sec, it doesn't go up and down like with 11ac.
> >
> > Anyway, I'll see if I can find myself another AP to deploy here, maybe it's 
> > just some
> > fringe compatibility issue.
> >
> > Daniel
> 
> Just for the record, I totally missed trying the 2.4GHz SSID of this AP (it 
> has a different name). I was only trying 5GHz with all modes - no wonder .11g 
> wouldn't join (brain freeze)...
> So .11n actually works on 2.4GHz with this AP and iwm(4), and has a download 
> speed of around 1,5-2,0MByte.
> 
> Daniel
> 
> 

This means the performance issue is specific to 11ac mode, correct?

If so, could you send me a pcap of 5GHz beacons from this AP?

To capture beacons, associate to the AP again (the easy way to ensure we
don't capture unrelated things):

 ifconfig iwm0 join apname chan 44 wpakey ...

Once 'status:' shown by ifconfig iwm0 is "actve", run this for about one second,
then terminate with Ctrl-C:

  tcpdump -n -i iwm0 -s 1500 -w /tmp/iwm.pcap -y IEEE802_11_RADIO type mgt 
subtype beacon

To verify whether the file contains the expected beacons, run:

  tcpdump -r /tmp/iwm.pcap | grep beacon

You should see at least one line such as:

  09:18:15.918261 802.11: beacon, ssid (apname), rates, ds, tim, country, rsn, 
70:5, 59:2, htcaps, htop, 127:8, vhtcaps, vhtop

Now send me the iwm.pcap file offlist. Thanks!



Re: Weird network performance with iwn(4)

2023-12-07 Thread Stefan Sperling
On Thu, Dec 07, 2023 at 03:39:33PM +, Lévai, Dániel wrote:
> Hi all!
> 
> Recently my trusty T410 died (had iwn(4) in it) and had to switch to an E450 
> - but this has iwm(4).
> Never had any issues with iwn(4) and iwm(4) seems to operate perfectly fine 
> in some scenarios, e.g. speedtest.net indicates 100/100Mbit down/up speed.

> But downloading a base74.tgz set takes little more than 30 minutes - in 
> firefox and in console with ftp(1).

So you are getting 100/100 Mbit on iwm(4) in a speed test, and only downloading
base74.tgz is slow? The speed test being successful would imply that the wifi
layer is working just fine. If so then something else must be messing with
your base74.tgz download attempts.

What happens when you download base74.tgz over ethernet?
Or with iwm(4) via a different AP? 
Or with iwm(4) via a different ISP?



Re: Getting stuck on trying a fresh install to 7.4

2023-12-06 Thread Stefan Sperling
On Wed, Dec 06, 2023 at 03:08:09PM -0500, Daniel Ouellet wrote:
> Hi,
> 
> Hopefully you may have a clue stick to offer me.
> 
> I try to do a fresh install on servers that run 6.7 to 7.4, but no matter
> what I try, I get stuck.
> 
> I tried previous version and I was able to load 7.3. DMESG below for the
> bsd.rd.
> 
> I try BIOS change for EFI ONLY, or Legacy & EFI, or Legacy only. No eval.
> 
> It's not the console issue either.
> 
> I try to boot -c and disable the efi, no difference.
> 
> I try to load the bdr.rd i386 to see, or the amd64, still on both case no
> eval and I put before the different output of each one. The i386 reboot
> after a few second, the amd64 get stuck until I force a reboot.
> 
> I put the actual working dmesg of the current install s wlel for more info.
> 
> On google I saw a few reference at the output I got saying may be the cpu
> doesn't support 64 bits, bnut it is and have been runnign the AMD for years.
> So that's not it either.
> 
> That really shoildn't make a difference, but just for the records, I also
> run softradi on these servers as shown below.
> 
> Could this be a cause may be?
> 
> Any suggestion woudl be greattly appreciated.

Old boot loaders cannot boot 7.4 kernels.
Upgrade your 6.7 system to 7.3 first (the usual advice to avoid
skipping releases during upgrades applies). Then upgrade to 7.4.

Or try booting fresh 7.4 install media from a USB stick.



Re: umb0: open error: FAILURE

2023-11-14 Thread Stefan Sperling
On Mon, Nov 13, 2023 at 11:46:14PM +0300, Samuel Jayden wrote:
> Hello Stefan(s),
> 
> Thanks for your replies.
> In my setup PIN is disabled.Also I've just tried entering { ifconfig umb0
> down;ifconfig umb0 apn internet;ifconfig umb0 pin "";ifconfig umb0 up } But
> nothing comes up.
> It is still at the same stage.

Checking the code, the "PIN required" state is a default state which
gets upgraded by a specific status message received from the device.
So perhaps this message from ifconfig is misleading, and the device
never tells us what the actual SIM state is.

Are you sure the APN "internet" is correct?
If not then please check with your ISP, they should be able to
tell you the APN to use.

There is also the 'ifconfig umb0 debug' command which will show debug
output from umb in dmesg and /var/log/messages once the interface starts
operating. Perhaps that will provide hints about the connection failure.



Re: umb0: open error: FAILURE

2023-11-13 Thread Stefan Sperling
On Mon, Nov 13, 2023 at 10:03:01PM +0300, Samuel Jayden wrote:
> Hello misc,
> 
> After experiencing mbim attach (from umsm) issue[*] with EM7455, I
> purchased another LTE module with a different   (SIM8262E-M2) chipset. This
> time switching to mbim mode was no problem.
> However, this time it remains as "SIM not initialized". But when you
> install Linux on the same device, it can successfully obtain an IP address
> and access the internet.
 
This is the important bit in your logs:

> SIM not initialized PIN required
 ^^

Try setting the SIM card's PIN with 'ifconfig umb0 pin '.

On my laptop I have this in /etc/hostname.umb0 (with the correct
pin instead of  and the correct APN):

pin 
apn myapn
roaming
down

With this in place running 'ifconfig umb0 up' is enough to get link.



Re: OnLogic Helix 330

2023-11-07 Thread Stefan Sperling
On Tue, Nov 07, 2023 at 09:17:57PM -, Stuart Henderson wrote:
> On 2023-11-07, Devin Reade  wrote:
> > I recently acquired an OnLogic Helix 330 (see [1] and [2]) and booted
> > the 7.4 install image via USB; no installation yet, no serial console
> > configured yet, no sharable dmesg yet.
> >
> > I have the version with the four network interfaces, based on the
> > J6426.  Dropping to shell from the 7.4 install image, it looks like
> > ony two of the four are detected, via em(4) as I210.  Interestingly,
> > it is the two on the add-on board rather than the two integrated
> > ports, based on the link status in ifconfig(8).
> >
> > The underlying network hardware is a Maxlinear GPY115 per [3].
> > 
> > Booting into Debian 12, all four interfaces are detected.  It looks like
> > support for the GPY115 is relatively new there.
> 
> GPY115 is a PHY, the NIC is dwqe(4), which was only recently supported
> on non-ARM. Try -current before spending any more time on it.

It seems this particular PHY is not yet supported.

At present we are only attaching dwqe to one of several possible MAC
PCI IDs because I don't have other hardware to test on. Help towards
adding support for more devices would be very welcome.



Re: 7.3 -> 7.4 WireGuard AllowedIPs stopped working

2023-10-22 Thread Stefan Sperling
On Sun, Oct 22, 2023 at 05:56:28PM +0200, Pierre Peyronnel wrote:
> Hi there,
> 
> Since upgrading from 7.3 to 7.4 my wireguard setup stopped working.
> Now, it might be me. Still here's what I have.
> 
> Stripping down wg0.conf, I have this message as soon as I add a [Peer]
> section and its public key:
> 
> bsd# cat /etc/wireguard/wg0.conf
> >
> > [Interface]
> > PrivateKey = (hidden by me)
> > ListenPort = 51820
> >
> > [Peer]
> > PublicKey = (hidden by me)
> > #PresharedKey = (hidden by me)
> > #AllowedIPs = 10.x.x.10/32
> >
> 
> 
> > # wg setconf wg0 /etc/wireguard/wg0.conf
> > Unable to modify interface: Address family not supported by protocol family
> >
> 
> Trying to set it up manually, I get the following result:
> 
> > bsd# ifconfig wg0 wgpeer '(hidden by me)' wgpsk '(hidden by me)' wgaip
> > '10.x.x.10/32'
> > bsd# wg
> > interface: wg0
> >   public key: (hidden by me)
> >   private key: (hidden)
> >   listening port: 51820
> >
> > peer: (hidden by me)
> >   preshared key: (hidden)
> >   allowed ips: (none)
> >

Maybe this 'wg' tool just doesn't display the config correctly? 
ifconfig wg0 as root displays wgaip settings just fine here.

For automatic setup you can set up wg0 via /etc/hostname.wg0, adding
all the ifconfig wg0 commands you need on a single line.
There is no need to use any files in /etc/wireguard anymore, nor is
there a need for a wireguard config tool from packages.

My /etc/hostname.wg0 looks like this (except that the random keys
and IPs are in fact different):

rdomain 1
wgkey "86oHs/awV8nlLe2KKHkMEAhmsRRIA8nLilzHwnFFP8A=" wgpeer 
"6e0ZhZs/q4R8JZjNTp973DlO0FDRrkCiHAnMinFfn1U=" wgaip 0.0.0.0/0 wgaip ::/0 
wgendpoint 10.10.10.10 443 wgpsk "ksorfAqLmd+CteNrc+aNL/q/5ItL6B2qZDllYNEgvqk=" 
wgpka 25 wgrtable 0
mtu 1332
inet 10.2.2.4/24
inet6 2001:db8::4/64
!/sbin/route -T1 add -inet default 10.2.2.1
!/sbin/route -T1 add -inet6 default 2001:db8::1



Re: Slow relink in 7.4

2023-10-17 Thread Stefan Sperling
On Tue, Oct 17, 2023 at 05:07:15AM -0400, David Higgs wrote:
> I have an underpowered amd64 VPS and attempted to (auto)upgrade it to 7.4.
> Everything went swimmingly until it attempted to relink the kernel, at
> which point it (seemingly) hung.
> 
> With previous releases, I would expect the host to become unresponsive for
> a few minutes, and eventually recover. I chalked the issue up to
> insufficient RAM and hitting swap - however, my upgrade has been in this
> state for more than 6 hours.
> 
> I plan to consult the manual upgrade guide to hopefully figure out a way to
> successfully finish the install, and then disable relinking while I find a
> solution.
> 
> Does anyone have tips for this situation, aside from throwing more hardware
> at it?
> 
> Thanks!

Try adding more RAM. Swapping can deadlock.
The issue is being worked on in -current:
https://marc.info/?l=openbsd-cvs=169745580119640=2



Re: Compulab's Fitlet3: Intel's Elkhart Atom X6425E with MARVELL PHY 88E1512 Ethernet

2023-10-11 Thread Stefan Sperling
On Mon, Sep 18, 2023 at 09:15:48AM +0200, Wolfgang Oelerich wrote:
> ok; thank you for the quick reply. 

The next amd64 -current snapshot should have dwqe(4) attach to at
least one of the Elkhart Lake interfaces of your system, provided
it has PCI product Id 4ba0 in pcidump -vv output.

> > Am 15.09.2023 um 21:54 schrieb Stefan Sperling :
> > On Fri, Sep 15, 2023 at 04:55:42PM +0200, Wolfgang Oelerich wrote:
> >> Hello,
> >> 
> >> recently, I „inherited“ one of Compulab‘s Fitlet3. I received it with 
> >> Linux Mint installed and found all 4 available Ethernet ports working: 
> >> 2 of its extensional FACET card and 2 of Intel‘s Elkhart Lake Atom X6425E 
> >> with MARVELL-type PHY „88E1512" at Atom's PCIe bus (see link below). 
> >> 
> >> Now, I tried a clean install of OpenBSD 7.3/AMD64 which smoothly worked 
> >> out but only the FACET card Ethernet ports have been recognized properly. 
> >> While assuming BIOS is ok since Linux Mint worked I am wondering how far 
> >> the hardware combination of X6425E/MARVELL PHY 88E1512 is already set to 
> >> be working or if there is some driver or other Kernel level code not 
> >> available yet.
> > 
> > Elkhart Lake Ethernet will require PCI attachment code to be written
> > for dwqe(4). There is interest in getting this working but it will take
> > time. Definitely won't be ready for OpenBSD 7.4. Maybe 7.5.
> 
> 



Re: Compulab's Fitlet3: Intel's Elkhart Atom X6425E with MARVELL PHY 88E1512 Ethernet

2023-09-15 Thread Stefan Sperling
On Fri, Sep 15, 2023 at 04:55:42PM +0200, Wolfgang Oelerich wrote:
> Hello,
> 
> recently, I „inherited“ one of Compulab‘s Fitlet3. I received it with 
> Linux Mint installed and found all 4 available Ethernet ports working: 
> 2 of its extensional FACET card and 2 of Intel‘s Elkhart Lake Atom X6425E 
> with MARVELL-type PHY „88E1512" at Atom's PCIe bus (see link below). 
> 
> Now, I tried a clean install of OpenBSD 7.3/AMD64 which smoothly worked 
> out but only the FACET card Ethernet ports have been recognized properly. 
> While assuming BIOS is ok since Linux Mint worked I am wondering how far 
> the hardware combination of X6425E/MARVELL PHY 88E1512 is already set to 
> be working or if there is some driver or other Kernel level code not 
> available yet.

Elkhart Lake Ethernet will require PCI attachment code to be written
for dwqe(4). There is interest in getting this working but it will take
time. Definitely won't be ready for OpenBSD 7.4. Maybe 7.5.



Re: Does openBSD come with a web browser?

2023-09-13 Thread Stefan Sperling
On Wed, Sep 13, 2023 at 01:38:30AM +, 0x1eef wrote:
> The only feature not working out of the box was wifi. But you 
> can buy a USB dongle to compensate for that.

Laptops with built-in Intel wifi will give you 11ac with up to 300
(three hundred) Mbit/s. Any of AX200/AX201/AX210/AX211 will do.
Suspend/resume works, and seamless roaming between APs is supported.

All supported USB dongles will only work in 11a/b/g modes due to
driver limitations. In practice I would expect throughput to max out
at around 10 (ten) Mbit/s, often much less. USB devices need to be
reconfigured after suspend/resume either manually or via hotdplugd.
None of the USB drivers support roaming between APs. So if you walk
out of range or the AP drops off the air you need to down/up the
interface yourself.

There's also broadcom 11ac for specific devices used on some arm64
platforms. It is less common on x86 than the Intel ones.

Hopefully more chipsets will get 11ac support later. But for now if you
can get built-in Intel or (supported) Broadcom then that's the obvious
choice if you are buying a laptop today and want to use wifi on OpenBSD.



Re: dmesg of ThinkPad P14s G3 (AMD)

2023-07-28 Thread Stefan Sperling
On Fri, Jul 28, 2023 at 03:32:38PM +0200, Marco van Hulten wrote:
> Doesn't work:
> - Wi-Fi (soldered)

> "Qualcomm QCNFA765" rev 0x01 at pci2 dev 0 function 0 not configured

This is being worked on but will still take a while (not sure how long).



Re: patch-008 missing in CVS repo

2023-07-13 Thread Stefan Sperling
On Thu, Jul 13, 2023 at 08:49:06AM -0500, Brian Conway wrote:
> On Thu, Jul 13, 2023, at 12:40 AM, Yoshihiro Kawamata wrote:
> > Of the recently announced OpenBSD 7.3 patches 006 through 009,
> > 008 cannot be found on CVSweb.
> >
> > And even after cvs update, sys/kern/exec_elf.c remains unfixed.
> >
> > But, I was able to find patch-008 on GitHub.
> >
> > 
> > Yoshihiro Kawamata
> > https://fuguita.org
> 
> I'm seeing the same. The commit email for 7.3-stable is here:
> 
> https://marc.info/?l=openbsd-cvs=168919043301821
> 
> But exec_elf.c shows no changes in the past 4 weeks to any branch:
> 
> https://cvsweb.openbsd.org/src/sys/kern/exec_elf.c
> 
> I see similar results when I try pulling from a couple anoncvs mirrors. 
> Perhaps a bug or oops in the CVS update process?

Keep waiting while more of Canada wakes up and it will likely get resolved.
In the meantime you could fetch the patch from the errata page and apply
it locally.



Re: Weird cvs diff of recent httpd changes on OPENBSD_7_2 branch

2023-07-12 Thread Stefan Sperling
On Wed, Jul 12, 2023 at 06:28:47PM +0200, Matthias Pressfreund wrote:
> Why does 'cvs diff -D...' on the OPENBSD_7_2 branch
> include changes from before the given date?

Because cvs -D resolves to the most recent revision no later than
the given date, and the OPENBSD_7_2 tag contains files that were
not modified since OPENBSD_7_1.

For instance, config.c has the same revision in OPENBSD_7_1 and
OPENBSD_7_2. The latest change to that file on the OPENBSD_7_2 branch,
no newer than -D2023-07-11, happened before 7.1 was tagged.
There is a newer config.c change on HEAD and OPENBSD_7_3 but you won't
see that change in a working copy checked out with -rOPENBSD_7_2.



Re: IPsec over PPPoE

2023-06-28 Thread Stefan Sperling
On Wed, Jun 28, 2023 at 09:53:38AM +0200, Jiri Navratil wrote:
> 3) The sites I'm configuring are both using PPPoE. One have VLAN and I
> see external statical IPv4 on PPPoE, but other site uses NAT 1:1, so I
> see private IPv4 on PPPoE, but I have to access it over allocated
> external IPv4. I'm not sure, which IP comes where. I switched responder
> and initiator, to have responder on site with VLAN, but anyway I'm not
> sure, where in pf.conf and /etc/iked.conf use external and where NAT IP.

Flow source/destination IPs must exactly match packets leaving the box.

So you will either need to put the private IP as the from "src" of the
flow (which can be annoying if it changes at run-time, you need to adjust
and reload flows somehow when the private IP changes) or use "any" as
source with the other end's static public IP as the destination (and be
careful with your flow traffic selectors if you still need to send some
traffic towards the other side without IPsec).

Flows towards a box behind NAT need to use the NAT's public IP to match
outgoing packets sent towards the internet.

You can ignore 'srcnat' in this context. 'srcnat' could be used later
to NAT traffic which crosses the tunnel, once the tunnel is working.

> 4) Using enc0 in pf.conf not worked. I had to switch to pppoe. Is that
> correct? No rules for enc0 and vlan?

You can just set skip on enc0 until it is working. Filtering on enc0 is
only needed if you want to prevent some traffic matched by flows from
crossing the tunnel (depending on the situation, adjusting flows to
avoid matching the unwanted traffic in the first place might be better).

> 4) I don't see any output from nc and tcdump commands. How I can see,
> which pf rule stops ping from other site?

Because one side is behind NAT the ESP packets should automatically be
encapsulated in UDP (ESP by itself cannot cross NAT).
You should see UDP packets on port 4500 (ipsec-nat-t) being exchanged,
both during handshakes and during regular operation of the tunnel.
These UDP packets need to pass all the way through for things to work.

> 5) There is note in FAQ, that Native WireGuard support is also
> available. As both IPsec and WireGuard are new to me, may wg(4) be an
> option?

Yes, you can try it as an alternative. It can be easier to get going across
NAT since external IP addresses don't matter to Wireguard. Wireguard only
cares about whether incoming packets have been signed with the correct key.



Re: Sony VAIO SVE15118FGB Keyboard and WiFi Issues

2023-05-29 Thread Stefan Sperling
On Mon, May 29, 2023 at 10:13:30PM +1200, Avon Robertson wrote:
> $ fgrep -e AR9485 *
> ar9003reg.h:#define AR9485_PHY_65NM_CH0_TOP2  0x16284
> ar9003reg.h:#define AR9485_PHY_CH0_XTAL   0x16290
> ar9003reg.h:/* Bits for AR9485_PHY_65NM_CH0_TOP2. */
> ar9003reg.h:#define AR9485_PHY_65NM_CH0_TOP2_XPABIASLVL_M 0xf000
> ar9003reg.h:#define AR9485_PHY_65NM_CH0_TOP2_XPABIASLVL_S 12
> ar9003reg.h:/* Bits for AR9485_PHY_CH0_XTAL. */
> ar9003reg.h:#define AR9485_PHY_CH0_XTAL_CAPINDAC_M0x7f00
> ar9003reg.h:#define AR9485_PHY_CH0_XTAL_CAPINDAC_S24
> ar9003reg.h:#define AR9485_PHY_CH0_XTAL_CAPOUTDAC_M   0x00fe
> ar9003reg.h:#define AR9485_PHY_CH0_XTAL_CAPOUTDAC_S   17
> ar9380.c: * Routines for AR9380 and AR9485 chipsets.
> ar9380.c: reg = AR_READ(sc, AR9485_PHY_65NM_CH0_TOP2);
> ar9380.c: reg = RW(reg, AR9485_PHY_65NM_CH0_TOP2_XPABIASLVL,
> ar9380.c: AR_WRITE(sc, AR9485_PHY_65NM_CH0_TOP2, reg);
> ar9380.c: reg = AR_READ(sc, AR9485_PHY_CH0_XTAL);
> ar9380.c: reg = RW(reg, AR9485_PHY_CH0_XTAL_CAPINDAC,
> ar9380.c: reg = RW(reg, AR9485_PHY_CH0_XTAL_CAPOUTDAC,
> ar9380.c: AR_WRITE(sc, AR9485_PHY_CH0_XTAL, reg);
> ar9380reg.h: * AR9485 1.1 programming.
> ar9380reg.h: * AR9485 1.1 Tx gains.
> ar9380reg.h: * AR9485 1.1 Rx gains.
> athn.c:   return ("AR9485");
> 
> Am I missing something w.r.t. enabling the athn interface OR is the
> Atheros AR9485 chip really unsupported?  The dmesg output identifies it
> as having a rom address conflict and as having an unconfigured function
> 0.

The ar9380.c parts of this driver are intentionally disabled because they
do not work. I would be happy to review and test patches that improve
this sad situation.



Re: Overwriting softraid keys

2023-05-25 Thread Stefan Sperling
On Wed, May 24, 2023 at 04:37:00PM +, Francesco Toscan wrote:
> Hi misc@,
>
> I'm going to migrate a FreeBSD ZFS-based fileserver to a OpenBSD 7.3 
> UFS-based one.
> In order to comply with regulations, part of data must be encrypted; 
> regulations also dictate that I have to be able to destroy the encryption 
> keys.
>
> So, I want to split data into multiple partitions, mounted read-only (it's 
> "cold" data, there's no point in mounting rw); one of them, of about 50GB, 
> will be a chunk dedicated to softraid. The volume will be assembled by hand 
> and the on-disk encryption key will be encrypted with a user supplied 
> password (right, regulations).
> If I understand correctly the 2010 paper by Marco Peereboom, he designed the 
> crypto softraid discipline so the encrypted keys would be saved in a variable 
> part of softraid medatata, stored at the beginning of the chosen chunk, after 
> an offset of 512 bytes.
> To "destroy" the keys I think it could be sufficient to use dd and overwrite 
> the first megabyte of the softraid chunk with random data.
> Am I missing something?
>
> Thanks,
> f
>
>

Yes, indeed. There is only one section of meta-data at the beginning of the
chunk and if this meta-data is lost then the decryption key is gone as well.

The password ("mask key") read from user input by 'bioctl -cC' will not be
written to disk. It will be used to encrypt the volume key which is stored
on disk.  As such, bioctl should comply with your regulations out of the box.

There is also an option to use a key disk which stores a randomly generated
mask key in unencrypted form on an arbitrary RAID disklabel partition, which
would usually sit on an external USB drive or SD card. This replaces the
passphrase with a physical object but otherwise behaves the same way.
Destroying the first 1MB of the softraid chunk would likewise render the
key disk useless.

It is not yet possible to encrypt a key disk with a passphrase, which would
provide two-factor authentication. There is no technical reason which would
prevent this from being implemented, it just hasn't been done.



Re: Asymmetric file encryption… use gnupg from ports or is there something else?

2023-05-10 Thread Stefan Sperling
On Wed, May 10, 2023 at 01:41:47PM +1000, Stuart Longland wrote:
> delivery.  I've certainly coaxed Taylor UUCP to work over SSH in the
> past, and it does work just fine.  Not sure if OpenBSD has a built-in
> UUCP, but that is an option.  It'd solve my immediate problem… but I
> figure if they're going to sit there any length of time, I might as
> well protect them from prying eyes if possible.
> 
> The aim here is not to defend against every possible attack, it's to
> defend against the most probable ones and keep people honest.

Mail is most likely leaking while in transit or sitting on servers you
have no control over. So putting lots of effort into protecting mail
on your backup MX might not make much of a difference in practice.

softraid CRYPTO or RAID1C works well for servers. It doesn't protect files
if someone gains access to the live system, or gains access to decrypted
blocks or volume key in VM memory space if you're running in a VM. But at
least the underlying disks or disk images will be unreadable. In a VM in
particular it's difficult to reliably protect data from the host system
so you'll have to trust the host.

You need a way to enter a passphrase at boot so this requires bootloader
access on the console. And a reboot happening for any reason requires
manual intervention. I am fine with those restrictions and it's been
worksing well for me on servers I run.

In any case, you could as well encrypt invididual files to make them
unreadable to people who manage to peek into the decrypted softraid
volume somehow.
For invidiual files I cannot think of tools that do this and have great
UIs. Maybe indeed try to script something around gnupg or perhaps openssl(1).
No good options come to mind...

Or accept that you'll have to use a volume to be somehow unlocked/locked
on demand and take a look at the security/encfs and security/veracrypt
ports, and vnconfig(8) -K. Nesting softraid volumes should be avoided.



Re: PC Engines APU platform EOL

2023-05-04 Thread Stefan Sperling
On Fri, May 05, 2023 at 03:42:37AM +1000, Damian McGuckin wrote:
> On Thu, 4 May 2023, Stefan Sperling wrote:
> 
> > The edgerouter 6p works with OpenBSD/octeon and has a rackmount bracket.
> 
> Wow. And it has a serial port. with an RJ45 connector. Hopefully the RS232
> pinouts are nicely documented somewhere. Cannot seem to find those details
> right now.

A cisco style rj45 serial cable works.

> I wonder whether the Edgerouter 8 with double the RAM is a wiser choice?
> 
> I will go and read the installation instructions for OpenBSD.
> 
> I see there was some feedback in 2018 from Bryan. He used an SSD mounted
> over the USB port (and had some issues). Looks like it works at up to about
> 450Mbps. Probably enough. Probably should test it against 7.3 then.

I have had one in production for 2 years until the USB stick failed.
It was working reliably up to that point.

An SSD would probably need an external power supply. I tried without
one and saw I/O errors. But I don't see why it wouldn't work with a
USB 3 to SATA adapter that also provides sufficient power.



Re: PC Engines APU platform EOL

2023-05-04 Thread Stefan Sperling
On Thu, May 04, 2023 at 09:45:27AM -0400, David Higgs wrote:
> On Thu, Apr 20, 2023 at 1:30 AM fRANz  wrote:
> 
> > On Wed, Apr 19, 2023 at 11:30 AM Martin Schröder 
> > wrote:
> >
> > > https://www.pcengines.ch/eol.htm
> > > The end is near for APUs :-(
> >
> > :(
> > Happy apu2 & apu4 user here.
> > Are there other OpenBSD friendly options?
> > Regards,
> > -f
> >
> 
> Someday I'll need to replace my APU and prefer not to wade through
> aliexpress.  If there aren't any spares left, it looks like the ODROID H3
> with the expansion NIC board might be a good match for my needs.
> https://www.hardkernel.com/shop/odroid-h3/
> https://www.hardkernel.com/shop/h2-net-card/
> 
> Someone recently posted a dmesg too:
> https://marc.info/?l=openbsd-misc=168182784030477=2
> 
> I've got no particular affinity for x86 hardware.  Has anyone found an
> equivalent that can run arm64 with a minimum of installation fussiness and
> 3x NICs?

The edgerouter 6p works with OpenBSD/octeon and has a rackmount bracket.



Re: PC Engines APU2 infinite loop rebooting immediate after kernel loads

2023-04-18 Thread Stefan Sperling
On Mon, Apr 17, 2023 at 05:23:05PM -0700, Jonathan Thornburg wrote:
> *Summary*
> I have a PC Engines APU2 with a wierd problem: on power-on it starts
> executing the PC Engines coreboot as it should, loads the OpenBSD boot
> loader, and the OpenBSD boot loader then loads an OpenBSD kernel (either
> 7.2/amd64 bsd.rd from an SD card *or* 7.3/amd64 bsd.rd from a USB stick).
> But immediately after printing
>   entry point at 0x8100100
> the APU2 reboots.  Memtest86 doesn't find anything wrong with the hardware.
> Has anyone else seen these symptoms and/or have any suggestions for further
> troubleshooting?

> Loading..
> probing: pc0 com0 com1 com2 com3 mem[639KKESC[08;42H 3325M 752M a20=on] 
> disk: hd0+
> >> OpenBSD/amd64 BOOT 3.55
> boot> 
> cannot open hd0a:/etc/random.seed: No such file or directory
> booting hd0a:/7.2/amd64/bsd.rd: 3916484+1639424+3884040+0+704512 
> [109+438912+292
> 606]=0xa61d70
> entry point at 0x8100100PC Engines apu4
> coreboot build 20202905
> BIOS version v4.12.0.1
> 4080 MB ECC DRAM

You forgot about setting up the serial console in the boot loader:

boot> stty com0 115200
boot> set tty com0
boot> boot bsd.rd



Re: iwm adapter loses connectivity to 2.4Ghz network

2023-04-08 Thread Stefan Sperling
On Sat, Apr 08, 2023 at 11:07:59AM -0500, rea...@catastrophe.net wrote:
> I'm running 7.2 with an iwm(4) controller connected to a 2.4Ghz network.
> 
> Every few days the device loses connectivity and can't rejoin the network
> without a reboot. 
> 
> 
> /var/log/messages shows this:
> 
> iwm0: hw rev 0x140, fw ver 17.3216344376.0, address 80:19:34:ab:ab:ab
> iwm0: device timeout
> iwm0: acquiring device failed
> iwm0: acquiring device failed
> iwm0: acquiring device failed
> iwm0: acquiring device failed
> iwm0: acquiring device failed
> iwm0: apm init error 16
> iwm0: could not initialize hardware

"acquiring device failed" means the driver has asked the device to
wake up such that its internal registers can be accessed, and the
device failed to wake up. When this request to wake is failing then
nothing else can be expected to work since access to device registers
is a prerequisite for anything else the driver does.

So this looks like the device is having some issue that cannot be
recovered by the driver. Like an inadequate power supply or the card
falling off the PCI bus for some reason (anything from bad electrical
contacts to PCI bus power management issues).



Re: athn on a bridge

2023-02-09 Thread Stefan Sperling
On Thu, Feb 09, 2023 at 08:39:50AM -0300, Crystal Kolipe wrote:
> On Thu, Feb 09, 2023 at 06:51:54AM +0100, Martin Kjr Jrgensen wrote:
> > That's what I gathered so far, but I could have been wrong or not
> > up-to-date. There have been some work on the ieee80211(9) lately.
> 
> I've just done a quick test using:
> 
> athn0 at pci1 dev 0 function 0 "Atheros AR9287" rev 0x01: apic 2 int 16
> athn0: AR9287 rev 2 (2T2R), ROM rev 4, address xx:xx:xx:xx:xx:xx
> 
> ... in hostap mode.
> 
> I've used this particular card with OpenBSD since 6.1, and other athn
> cards before it during the 5.* days.  One long standing issue has been
> that the transmission rate always seemed to drop to DS1 as soon as any
> data was transferred, and stay there (*).
> 
> At least in this casual test this morning, I was able to transfer 1.5 Gb
> of data at about 24 Mbps.
> 
> So maybe one of the many issues has been resolved, or at least seen some
> improvement.
> 
> But this was a casual test with a single client, so it ignores many of
> the other problems that plagued hostap mode on OpenBSD.  More testing is
> definitely required.
> 
> (*) Actually it was a bit more complicated than that, from what I
> remember the transmission rate on the host seemed to stay low when
> the flow of data was mostly from client to host.  Running a ping with
> a very low latency, but not enough to flood the connection bandwidth,
> E.G. ping -i 0.1 from the server to the client, caused the
> transmission rate to increase.

This was likely because of the AMRR algorithm use in 11a/11g modes, which
only counts Tx retries. And this hardware is very prone to reporting retries
under high Tx load, likely because our driver is getting some details wrong.
In 11n modes drivers are now using a better algorithm where actual throughput
is measured and the Tx rate is adjusted based on that, so these retries don't
carry as much weight anymore.

There are several issues which remain. In particular, some athn devices
tend to run into "device timeout" problems, meaning they fail to Tx for
some reason.
And the driver lacks 11n Tx aggregation and 40MHz channel support.
In theory the hardware should be able to provide 100 Mbit/s or more to
clients once those features get added.
And the code we have for 3-antenna variants of this hardware doesn't work and
is currently disabled at run-time, though still compiled into the kernel.
So, yes, there is a lot of work left to be done in this driver which is
up for grabs if someone seriously wants to clench their teeth into this.
There is working code in Linux and FreeBSD which can be used as a reference.
I have already spent more time on this than I ever really wanted to.

You could also try to find a card supported by bwfm(4). This bypasses
the entire OpenBSD wifi stack and runs everything in firmware. But it
should provide proper 11n or even 11ac speeds towards clients.



Re: amd64 vmm(4) virtual machine "powers off" instead of rebooting when started with "-B disk"

2022-12-29 Thread Stefan Sperling
On Thu, Dec 29, 2022 at 04:05:44PM +0100, Jurjen Oskam wrote:
> > It has been this way since day-1 of -B -- unclear if you want to call
> > it expected, feature or bug :-)
> 
> Ah, thanks! No need to dive into it then, and hopefully this thread
> will pop up in searches for others running into the same phenomenon.
> :)

I also ran into this a few months ago after adding 'boot device disk'
to my vm.conf.

Turns out this is indeed intentional and allows -B to be used as a "oneshot"
boot for unattended installation. It keeps the freshly installed system from
rebooting into the installer again and then keep looping like that.

It has been noted before that this is not obvious and collides with other
use cases. A more explicit way of asking vmd to run a VM just once would
be welcome, and then -B could be changed to behave as usual upon 'reboot'.

This is a known issue to vmm developers, but not a high priority one.



Re: Lenovo ThinkPad X1 Carbon G10

2022-11-15 Thread Stefan Sperling
On Tue, Nov 15, 2022 at 01:07:04PM +0100, Rafael Sadowski wrote:
> On Sat Nov 12, 2022 at 09:01:58AM +0100, Rafael Sadowski wrote:
> > Hi misc@
> > 
> > Can anyone recommend the "Lenovo ThinkPad X1 Carbon G10 21CB00B9GE" with
> > OpenBSD and has experience with it? Would appreciate any reports of
> > experience or an assessment.
> > 
> > Cheers Rafael
> > 
> 
> Looks bad, doesn't it? Do we at least know if the wifi is working?

On paper, wifi seems to be AX211, i.e. iwx(4), according to:
https://www.notebookcheck.net/Lenovo-ThinkPad-X1-Carbon-G10-21CB00B9GE.652571.0.html



Re: PC Engines APU alternative for OpenBSD - 2022h2

2022-09-28 Thread Stefan Sperling
On Wed, Sep 28, 2022 at 02:27:48PM +, Mikolaj Kucharski wrote:
> Hi,
> 
> I'm using PC Engines for years. I have many of them. I want to buy more,
> but they are not available on their main web site. I'm still planning to
> buy them the moment they will show up on https://www.pcengines.ch/order.htm
> 
> However, after many weeks of waiting, I finally reached a point, when I
> need to look for alternatives, as few of my hobbyist projects and plans
> are on-hold for too long.
> 
> 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,

jetway JBC430U941 are a decent alternative but they are also out
of stock everywhere.



Re: Updating iwx firmware to 20220708 from 7.2 branch

2022-09-17 Thread Stefan Sperling
On Sat, Sep 17, 2022 at 09:17:03PM +0200, Quentin Schibler wrote:
> I have a laptop using an AX210 network card (no ethernet), 
> which is supported by -current, but not by 7.1.
> I installed 7.1 without configuring network,
> rebooted, and dumped the iwx firmware
> 20220708 onto a USB key.
> 
> I tried to fw_update -p . but it did not detected
> iwx as added iwx.
> I tried fw_update -p . iwx, it added iwx, updated
> none, kept none. The interface did not showed
> up with ifconfig. Then I sh /etc/netstart, it does
> not output anything, and the interface does not
> appear. Running fw_update -d iwx yields "No 
> firmware found for iwx", which makes me think
> that the previous fw_update command did not
> worked.
> 
> - Quentin

You need to upgrade to -current to get AX210 support, or wait for 7.2.

fw_update will not pull in support for newer devices.
The purpose of fw_update is to install a set of firmware files which
is compatible with the installed version of OpenBSD. So fw_update will
fetch newer firmware only if the OpenBSD system as a whole has been
upgraded.



Re: Non-Disclosure Agreement

2022-08-31 Thread Stefan Sperling
On Wed, Aug 31, 2022 at 09:28:56AM +, O'Brien, Orla wrote:
> Hello,
> 
> My team in Dell Technologies are looking to use your software OpenSSH Client 
> 9 and OpenSSH Server 8. To do this our Cyber Security department require that 
> we sign a Non-Disclosure Agreement with you. Who would be the best person to 
> reach out to regarding this request?
> 
> Thank you for the help in advance.
> 
> Kind Regards,
> Orla.
> 

Hi Orla,

You can let your Cyber Security department know that there is nobody here
who is in a position to sign an NDA. The software is free to use by anyone
without restriction, and there is no formal licensing framework in place
that would allow the developers to tell who the active users are.

That said, the developers will gladly accept a pint of Murphy's as a
token of gratitude in case an opportunity arises :)
And donations to the OpenBSD foundation are always welcome at
https://www.openbsdfoundation.org/

With best regards, and with greetings to Cork which I hope to visit
again at some point,
Stefan



Re: dhcpcd sometimes fails to route ipv6 /48

2022-08-18 Thread Stefan Sperling
On Thu, Aug 18, 2022 at 02:06:47PM +0100, void wrote:
> Hello misc@,
> 
> I have an edgerouter lite 3 router running openbsd 7.1 octeon. The
> connection is via pppoe and has native ipv4 and ipv6.
> The router gets an ND /64 and PD /48. The /48 is served on the
> LAN-facing side.
> 
> This setup works well, usually. What sometimes happens is that
> a LAN machine won't get ipv6 routing; it'll just stop, no
> ping6 or anything. ipv4 continues to work fine and rcctl check dhcpcd says
> 'ok'. dhcpcd is not involved at all in ipv4. ipv6 works fine for a few days
> then stops again.
> 
> The workaround so far has been to restart dhcpcd. Then routing returns and
> ipv6 works normally from the LAN. From the router itself (so: using its ND
> v6 IP rather than the PD allocation) ipv6 works throughout.
> 
> How can I analyse this further? I don't know where to begin to
> look.
> 
> TIA
> 

Depending on what the IPv6 prefixes involved look like, this may be
a variation of the following problem in dhcpcd:
https://github.com/NetworkConfiguration/dhcpcd/pull/52

The fix for my specific problem described there is already in the
dhcpcd package on OpenBSD 7.0 and up. But your case is different.
In your case, the RB tree lookup might still be choosing the wrong
prefix to delete, because your LAN is a using wider prefix than the
WAN side. Assuming the final rt_cmp_netmask() call I added in
rt_cmp_dest() favours a /48 over a /64, then dhcpcd might still
be removing the wrong route for you.

If you can confirm that dhcpcd does in fact decide to remove your
LAN-side prefix, then please discuss your issue with dhcpcd upstream.



Re: iwx driver on AX210 (Framework laptop)

2022-07-06 Thread Stefan Sperling
On Wed, Jul 06, 2022 at 11:21:29AM +0300, Ioan Bizău wrote:
> Yup, I noticed that after checking the commit history. But I was wondering 
> how I can get a newer snapshot of the driver running in 7.1. I thought 
> fw_update would help if I get the snapshot from 
> http://firmware.openbsd.org/firmware/snapshots/ and save it to a USB stick, 
> but seems it doesn't.
> 
> sysupgrade is not an option since I don't have internet on that machine.
> 
> Is my only other choice then to run -current?

Your options are:

- run OpenBSD -current (AX210 works with 11n/11ac)
- use a supported USB wifi dongle for now, and wait for OpenBSD 7.2
- run Linux (has Intel vendor driver with 11n/11ac/11ax working)
- run FreeBSD 13.1 (AX210 probably works but only without 11n/11ac)



Re: iwx driver on AX210 (Framework laptop)

2022-07-06 Thread Stefan Sperling
On Wed, Jul 06, 2022 at 09:50:34AM +0300, Ioan Bizău wrote:
> Hi there!
> 
> Trying to get OpenBSD running the the Framework laptop. The issue seems to be 
> the AX210 wireless card which is not supported by the iwx driver that comes 
> with 7.1.


AX210 is only supported in -current.
Run sysupgrade -s and then it should work.

The 7.1 release does not contain the relevant changes to the driver.
To find out, see the commit history of the driver here:
https://cvsweb.openbsd.org/src/sys/dev/pci/if_iwx.c
The OPENBSD_7_1 tag sits on revision 1.140, any changes above that
are only available in -current snapshots.



Re: Wireless network interface remembering join list across /etc/netstart.

2022-06-21 Thread Stefan Sperling
On Mon, Jun 20, 2022 at 11:41:05PM +0100, Julian Smith wrote:
> Recently i got really confused after removing a 'join  ... ' line
> from /etc/hostname.iwn0, then running `sh /etc/netstart`. This resulted
> in reconnection to , even though  was now not mentioned
> anywhere in /etc/hostname.iwn0.
> 
> Even `ifconfig iwn0 down up` did not change this behaviour.
> 
> It turned out that i needed to do `ifconfig iwn0 down -joinlist up` to remove
> all networks from the join list, as described in ifconfig(8). [I'm not
> actually sure that the `down` and `up` are necessary.]
> 
> Would it be possible and make sense to have /etc/netstart do this
> automatically for wireless interfaces? Or am i misunderstanding what
> /etc/netstart is for?

You could add the following as the first line of hostname.if if you
would like netstart to clear out existing networks before adding new
ones:

-joinlist



Re: iwn0: fatal firmware error after sysupgrade to 7.1

2022-06-15 Thread Stefan Sperling
On Wed, Jun 15, 2022 at 03:38:15AM +0200, Christian Schulte wrote:
> 
> 
> On 14.06.22 11:36, Stefan Sperling wrote:
> > I don't know what SYSASSERT 0x0005 is supposed to tell us. All
> > I can do is make guesses based on what changed between 7.0 and 7.1.
> > 
> > In addition to the previous change, this patch enables even more
> > debug output, and it delays enabling of 40MHz in the RXON command
> > until the association sequence has progressed to a later stage.
> > Does this make any difference?
> 
> Indeed. I am sending this email using the iwn0 interface which is up and
> running without any issues so far.

Nice. I have committed the fix just now. I hope all other iwn cards
will still be happy with this, but there is only one way to find out...



Re: iwn0: fatal firmware error after sysupgrade to 7.1

2022-06-14 Thread Stefan Sperling
On Tue, Jun 14, 2022 at 03:11:35AM +0200, Christian Schulte wrote:
> See attached files.

Thank you. I still don't have a definite clue. It looks as if we
are failing to send out the initial AUTH frame on Tx queue 0 but
it is unclear why.

The commands we are sending up to this point seem to be succeeding.
These are using Tx queue 4 and this queue has no outsanding frames queued.
This implies that the firmware managed to ack all of our commands before
it crashed. So processing of the commands seems to be working.

I don't know what SYSASSERT 0x0005 is supposed to tell us. All
I can do is make guesses based on what changed between 7.0 and 7.1.

In addition to the previous change, this patch enables even more
debug output, and it delays enabling of 40MHz in the RXON command
until the association sequence has progressed to a later stage.
Does this make any difference?

diff 83a9dfe1b143d86e38d14e824e87df26892a9d48 /usr/src
blob - 1446e2d9c7d71bb1360e96b018c63d06695fc23f
file + sys/dev/pci/if_iwn.c
--- sys/dev/pci/if_iwn.c
+++ sys/dev/pci/if_iwn.c
@@ -303,6 +303,7 @@ voidiwn_hw_stop(struct iwn_softc *);
 intiwn_init(struct ifnet *);
 void   iwn_stop(struct ifnet *);
 
+#define IWN_DEBUG
 #ifdef IWN_DEBUG
 #define DPRINTF(x) do { if (iwn_debug > 0) printf x; } while (0)
 #define DPRINTFN(n, x) do { if (iwn_debug >= (n)) printf x; } while (0)
@@ -3863,6 +3864,8 @@ iwn_cmd(struct iwn_softc *sc, int code, const void *bu
/* Update TX scheduler. */
ops->update_sched(sc, ring->qid, ring->cur, 0, 0);
 
+   if (sc->sc_ic.ic_if.if_flags & IFF_DEBUG)
+   printf("%s: sending command %d\n", sc->sc_dev.dv_xname, code);
/* Kick command ring. */
ring->cur = (ring->cur + 1) % IWN_TX_RING_COUNT;
IWN_WRITE(sc, IWN_HBUS_TARG_WRPTR, ring->qid << 8 | ring->cur);
@@ -5409,7 +5412,8 @@ iwn_rxon_configure_ht40(struct ieee80211com *ic, struc
sc->rxon.flags &= ~htole32(IWN_RXON_HT_CHANMODE_MIXED2040 |
IWN_RXON_HT_CHANMODE_PURE40 | IWN_RXON_HT_HT40MINUS);
 
-   if (ieee80211_node_supports_ht_chan40(ni) &&
+   if ((ni->ni_flags & IEEE80211_NODE_HT) &&
+   ieee80211_node_supports_ht_chan40(ni) &&
(sco == IEEE80211_HTOP0_SCO_SCA ||
sco == IEEE80211_HTOP0_SCO_SCB)) {
if (sco == IEEE80211_HTOP0_SCO_SCB)



Re: iwn0: fatal firmware error after sysupgrade to 7.1

2022-06-13 Thread Stefan Sperling
On Mon, Jun 13, 2022 at 02:45:23AM +0200, Christian Schulte wrote:
> 
> 
> On 12.06.22 13:22, Stefan Sperling wrote:
> > On Sun, Jun 12, 2022 at 01:16:00PM +0200, Stefan Sperling wrote:
> > > On Sun, Jun 12, 2022 at 10:28:33AM +0200, Christian Schulte wrote:
> > > > Please see attached dmesg and pcidump. There has been a similar issue 
> > > > with
> > > > the if_iwm.c driver. Maybe this one is related.
> > > 
> > > These are seperate drivers so it is unlikely that these issues would
> > > be related.
> > > 
> > > How many different access points have you tried to reproduce the
> > > problem with so far?
> 
> Two. The router and a repeater bridging the WLAN of that router. There are 3
> more repeaters I could test this with. Cannot be related to those. No issues
> with 7.0.
> 

I don't yet quite understand where the problem is.
I will need to see a beacon from an AP which triggers the problem in
order to decide what we should try next.

Can you please collect a fresh debug log again in the same way, and run
this command at the same time to record beacons:

tcpdump -n -i iwn0 -y IEEE802_11_RADIO -D in -s 4096 -w /tmp/iwn.pcap type mgt 
subtype beacon

Once the fw error has happened you can Ctrl-C tcpdump and send me your new
debug log and the pcap file which should now be stored at /tmp/iwn.pcap.
Hopefully we can make progress then.

Thanks!



Re: iwn0: fatal firmware error after sysupgrade to 7.1

2022-06-12 Thread Stefan Sperling
On Sun, Jun 12, 2022 at 01:16:00PM +0200, Stefan Sperling wrote:
> On Sun, Jun 12, 2022 at 10:28:33AM +0200, Christian Schulte wrote:
> > Please see attached dmesg and pcidump. There has been a similar issue with
> > the if_iwm.c driver. Maybe this one is related.
> 
> These are seperate drivers so it is unlikely that these issues would
> be related.
> 
> How many different access points have you tried to reproduce the
> problem with so far?

In any case we will need to figure out which command is failing for you.

The patch below adds additional debug output while 'ifconfig iwn0 debug'
is enabled and should display the command code sent to firmware. Hopefully
this can tell us which command firmware is complaining about.
Can you reproduce the failure with it again and send new debug output?

diff 83a9dfe1b143d86e38d14e824e87df26892a9d48 /usr/src
blob - 1446e2d9c7d71bb1360e96b018c63d06695fc23f
file + sys/dev/pci/if_iwn.c
--- sys/dev/pci/if_iwn.c
+++ sys/dev/pci/if_iwn.c
@@ -3863,6 +3863,8 @@ iwn_cmd(struct iwn_softc *sc, int code, const void *bu
/* Update TX scheduler. */
ops->update_sched(sc, ring->qid, ring->cur, 0, 0);
 
+   if (sc->sc_ic.ic_if.if_flags & IFF_DEBUG)
+   printf("%s: sending command %d\n", sc->sc_dev.dv_xname, code);
/* Kick command ring. */
ring->cur = (ring->cur + 1) % IWN_TX_RING_COUNT;
IWN_WRITE(sc, IWN_HBUS_TARG_WRPTR, ring->qid << 8 | ring->cur);



Re: iwn0: fatal firmware error after sysupgrade to 7.1

2022-06-12 Thread Stefan Sperling
On Sun, Jun 12, 2022 at 10:28:33AM +0200, Christian Schulte wrote:
> Please see attached dmesg and pcidump. There has been a similar issue with
> the if_iwm.c driver. Maybe this one is related.

These are seperate drivers so it is unlikely that these issues would
be related.

How many different access points have you tried to reproduce the
problem with so far?



Re: airport(7) and defunct airports

2022-06-10 Thread Stefan Sperling
On Fri, Jun 10, 2022 at 01:21:53PM -, Stuart Henderson wrote:
> On 2022-06-10, Moritz Röhrich  wrote:
> > In the end I don't think there is a right answer without defining
> > what purpose the list should serve. If it's an insider game for the
> > devs, documenting all the places where OpenBSD contributors have
> > been, removal is completely undesirable.
> 
> Yes that is pretty much the current status of the file.

I visit THF more often than any of the other airports on the list.



Re: iwm driver not working on starlabs starlite iv laptop

2022-06-02 Thread Stefan Sperling
On Wed, Jun 01, 2022 at 12:32:45AM +0100, Chris Narkiewicz wrote:
> > Can you please apply this patch, boot the resulting kernel, and
> > show me the new line that now appears in dmesg? It will show us
> > the antenna configuration of your device. 
> 
> So I applied the patch and this is the result:
> 
> iwm0: hw rev 0x310, fw ver 46.4e1ceb39.0, address 20:1e:88:77:66:72
> iwm0: valid Tx antenna masks: phycfg: 0x3 nvm: 0x1
> 
> I hope it leads somewhere. Thank you.

Let's try this patch. Does it help?

diff 98c04410ecc965030a8aa6f07102b14a69145a48 
54780b8cb6da1f75e7566af8b6117d93126a96b1
blob - 6de80bd303e3c03a8f4eb2533f54f65d4deebdd3
blob + 8b411c541a334905e8c6ba883bd8cabff15e999d
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -331,6 +331,9 @@ int iwm_nvm_read_chunk(struct iwm_softc *, uint16_t, u
uint8_t *, uint16_t *);
 intiwm_nvm_read_section(struct iwm_softc *, uint16_t, uint8_t *,
uint16_t *, size_t);
+uint8_tiwm_fw_valid_tx_ant(struct iwm_softc *);
+uint8_tiwm_fw_valid_rx_ant(struct iwm_softc *);
+intiwm_valid_siso_ant_rate_mask(struct iwm_softc *);
 void   iwm_init_channel_map(struct iwm_softc *, const uint16_t * const,
const uint8_t *nvm_channels, int nchan);
 intiwm_mimo_enabled(struct iwm_softc *);
@@ -3038,6 +3041,23 @@ iwm_fw_valid_rx_ant(struct iwm_softc *sc)
return rx_ant;
 }
 
+int
+iwm_valid_siso_ant_rate_mask(struct iwm_softc *sc)
+{
+   uint8_t valid_tx_ant = iwm_fw_valid_tx_ant(sc);
+
+   /*
+* According to the Linux driver, antenna B should be preferred
+* on 9k devices since it is not shared with bluetooth. However,
+* there are 9k devices which do not support antenna B at all.
+*/
+   if (sc->sc_device_family == IWM_DEVICE_FAMILY_9000 &&
+   (valid_tx_ant & IWM_ANT_B))
+   return IWM_RATE_MCS_ANT_B_MSK;
+
+   return IWM_RATE_MCS_ANT_A_MSK;
+}
+
 void
 iwm_init_channel_map(struct iwm_softc *sc, const uint16_t * const nvm_ch_flags,
 const uint8_t *nvm_channels, int nchan)
@@ -6628,10 +6648,8 @@ iwm_tx_fill_cmd(struct iwm_softc *sc, struct iwm_node 
if ((ni->ni_flags & IEEE80211_NODE_VHT) == 0 &&
iwm_is_mimo_ht_plcp(rinfo->ht_plcp))
rate_flags = IWM_RATE_MCS_ANT_AB_MSK;
-   else if (sc->sc_device_family == IWM_DEVICE_FAMILY_9000)
-   rate_flags = IWM_RATE_MCS_ANT_B_MSK;
else
-   rate_flags = IWM_RATE_MCS_ANT_A_MSK;
+   rate_flags = iwm_valid_siso_ant_rate_mask(sc);
if (IWM_RIDX_IS_CCK(ridx))
rate_flags |= IWM_RATE_MCS_CCK_MSK;
if ((ni->ni_flags & IEEE80211_NODE_HT) &&
@@ -9248,13 +9266,8 @@ iwm_set_rate_table_vht(struct iwm_node *in, struct iwm
IWM_RATE_VHT_MCS_NSS_MSK;
if (ni->ni_vht_ss > 1)
tab |= IWM_RATE_MCS_ANT_AB_MSK;
-   else {
-   if (sc->sc_device_family ==
-   IWM_DEVICE_FAMILY_9000)
-   tab |= IWM_RATE_MCS_ANT_B_MSK;
-   else
-   tab |= IWM_RATE_MCS_ANT_A_MSK;
-   }
+   else
+   tab |= iwm_valid_siso_ant_rate_mask(sc);
 
/*
 * First two Tx attempts may use 80MHz/40MHz/SGI.
@@ -9294,10 +9307,7 @@ iwm_set_rate_table_vht(struct iwm_node *in, struct iwm
} else {
/* Fill the rest with the lowest possible rate. */
tab = iwm_rates[ridx_min].plcp;
-   if (sc->sc_device_family == IWM_DEVICE_FAMILY_9000)
-   tab |= IWM_RATE_MCS_ANT_B_MSK;
-   else
-   tab |= IWM_RATE_MCS_ANT_A_MSK;
+   tab |= iwm_valid_siso_ant_rate_mask(sc);
if (ni->ni_vht_ss > 1 && lqcmd->mimo_delim == 0)
lqcmd->mimo_delim = i;
}
@@ -9378,10 +9388,8 @@ iwm_set_rate_table(struct iwm_node *in, struct iwm_lq_
 
if (iwm_is_mimo_ht_plcp(ht_plcp))
tab |= IWM_RATE_MCS_ANT_AB_MSK;
-   else if (sc->sc_device_family == IWM_DEVICE_FAMILY_9000)
-   tab |= IWM_RATE_MCS_ANT_B_MSK;
else
-   tab |= IWM_RATE_MCS_ANT_A_MSK;
+   tab |= iwm_valid_siso_ant_rate_mask(sc);
 
if (IWM_RIDX_IS_CCK(ridx))
tab |= IWM_RATE_MCS_CCK_MSK;
@@ -9395,10 +9403,7 @@ iwm_set_rate_table(struct iwm_node *in, struct iwm_lq_
tab = iwm_rates[ridx_min].plcp;
if (IWM_RIDX_IS_CCK(ridx_min))
tab |= IWM_RATE_MCS_CCK_MSK;
-   if (sc->sc_device_family 

Re: iwm driver not working on starlabs starlite iv laptop

2022-05-31 Thread Stefan Sperling
On Mon, May 30, 2022 at 11:58:23PM +0100, Chris Narkiewicz wrote:
> > Do you see this problem with every access point, or just a specific one?
> 
> I tried 2 APs with the same result.
> 
> > Do see the problem while forcing 11n/11ac off? To do this you could try
> > forcing the driver into 11a mode
> 
> Yes, my initial debug dmesg was generated using 11a mode.
> I have the same debug for 11ac, 11n and 11g modes.

Linux developers with access to magic tea leaves tell me that
sysassert code 0x19A8 is related to Tx antenna configuration
info which the driver sends as part of the failing LQ command.

Can you please apply this patch, boot the resulting kernel, and
show me the new line that now appears in dmesg? It will show us
the antenna configuration of your device. Apparently the driver is
trying to use an antenna which is invalid. If that is indeed the case,
knowing which antennas are considered valid by the device should allow
us to fix the issue.

diff 83a9dfe1b143d86e38d14e824e87df26892a9d48 /usr/src
blob - 6de80bd303e3c03a8f4eb2533f54f65d4deebdd3
file + sys/dev/pci/if_iwm.c
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -10161,6 +10161,10 @@ iwm_init_hw(struct iwm_softc *sc)
return EBUSY;
}
 
+   printf("%s: valid Tx antenna masks: phycfg: 0x%x nvm: 0x%x\n",
+   DEVNAME(sc), ((sc->sc_fw_phy_config & IWM_FW_PHY_CFG_TX_CHAIN)
+   >> IWM_FW_PHY_CFG_TX_CHAIN_POS), sc->sc_nvm.valid_tx_ant);
+
err = iwm_send_tx_ant_cfg(sc, iwm_fw_valid_tx_ant(sc));
if (err) {
printf("%s: could not init tx ant config (error %d)\n",




Re: iwm driver not working on starlabs starlite iv laptop

2022-05-30 Thread Stefan Sperling
On Mon, May 30, 2022 at 09:19:18PM +0100, Chris Narkiewicz wrote:
> Dnia Mon, May 30, 2022 at 10:09:19AM +0200, Stefan Sperling napisał(a):
> > A likely reason is that this device is mis-detected and we are loading
> > the wrong firmware image.
> > Please boot Linux with iwlwifi and check which fw image gets loaded there.
> > And the output of pcidump -vv on OpenBSD would help, too.
> 
> So, it looks like it's AC 9461 chip. It seems to be supported by FreeBSD:
> 
> https://www.freebsd.org/cgi/man.cgi?query=iwm=4=freebsd-release-ports
> 
> But OpenBSD does not have it on the list of supported hardware:
> 
> https://man.openbsd.org/iwm

9461 is just a 9560 with different branding displayed by the Linux
driver. The firmware being loaded is the same, and the device
should work the same way from the driver's perspective.
This looks fine to me, we are already using the right firmware image.

Looking for firmware SYSASSERT 0x19A8 I came across this:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1201470/
Which is a different issue but suggests that the error condition
you hit in firmware is related to channel configuration.
And it seems that your device is failing right after the driver
sends a "link quality" command (0x4e) which includes channel width
setup information for 11n and 11ac modes.

My next questions would be:

Do you see this problem with every access point, or just a specific one?

Do see the problem while forcing 11n/11ac off? To do this you could try
forcing the driver into 11a mode, for example: ifconfig iwm0 mode 11a
If that makes it work we could try to narrow it down from there.



Re: iwm driver not working on starlabs starlite iv laptop

2022-05-30 Thread Stefan Sperling
On Mon, May 30, 2022 at 02:09:23AM +0100, Chris Narkiewicz wrote:
> I got my hands on StarLabs StarLite laptop and I'm stuck with iwm
> driver issue.
> 
> I bootstrapped iwm-firmware-20220111.tgz and it seems to detect
> Intel AC 9560, firmware is loaded. But when the interface is configured,
> dmesg spews:
> 
> iwm0: fatal firmware error
> 
> Below is full dmesg output (I redacted WiFi ESSIDs, etc) with ifconfig iwm0 
> debug enabled.
> 
> Any help or suggestions will be appreciated.

A likely reason is that this device is mis-detected and we are loading
the wrong firmware image.
Please boot Linux with iwlwifi and check which fw image gets loaded there.
And the output of pcidump -vv on OpenBSD would help, too.



Re: Is there a way to build mod_auth_kerb?

2022-04-19 Thread Stefan Sperling
On Tue, Apr 19, 2022 at 12:23:31PM -, Stuart Henderson wrote:
> On 2022-04-18, Maksim Rodin  wrote:
> > Hello,
> > I am trying to build mod_auth_kerb for apache2 on OpenBSD 6.9
> > I installed heimdal-libs-7.7.0p0 and downloaded the latest src for
> > mod_auth_kerb from github
> > After unpacking and configuring the following way:
> > ./configure --with-krb5=/usr/local/heimdal --with-krb4=no
> > I try to run 'make'
> > I get a bunch of warnings like these:
> >
> > ```
> > /usr/local/heimdal/include/krb5-protos.h:18:52: note: expanded from macro 
> > 'KRB5_DEPRECATED_FUNCTION'
> > #define KRB5_DEPRECATED_FUNCTION(x) __attribute__((__deprecated__(x)))
> >^
> > src/mod_auth_kerb.c:1547:47: warning: incompatible pointer types passing 
> > 'request_rec *' (aka 'struct request_rec *') to parameter of type 'const 
> > char *'
> >   [-Wincompatible-pointer-types]
> > log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
> 
> This suggests that it is not compatible with the API of the version of
> Apache HTTPD that you're trying to use it with.
> 
> You might have better luck with https://github.com/S2-/mod_auth_kerb
> but that is still years old and might not work either

Last I looked at mod_auth_kerb (in the context of SVN server auth in my case),
it was is a dead end. It is a 3rd party module, written against Apache 1.x,
and was never updated to Apache 2.x APIs. And it has licencing issues.

Might have better luck with mod_auth_gssapi.



Re: time drift in OpenBSD in proxmox (qemu-kvm) guest

2022-04-14 Thread Stefan Sperling
On Thu, Apr 14, 2022 at 09:26:41PM -, Stuart Henderson wrote:
> I have some OpenBSD guests in Proxmox VE 7.1-7 (pve-qemu-kvm_6.1.0) and
> seeing pretty bad clock drift (50 seconds in ~7h uptime). ntpd can't cope
> with it. From boot:
> 
> 2022-04-14T13:58:19.844Z  ntpd[26996]: adjusting local clock by 1.745061s
> 2022-04-14T13:59:24.070Z  ntpd[26996]: adjusting local clock by 1.504470s
> 2022-04-14T14:03:51.176Z  ntpd[26996]: adjusting local clock by 2.430486s
> 2022-04-14T14:07:40.299Z  ntpd[26996]: adjusting local clock by 2.48s
> 2022-04-14T14:11:51.540Z  ntpd[26996]: adjusting local clock by 3.173884s
> 2022-04-14T14:15:03.534Z  ntpd[26996]: adjusting local clock by 3.109722s
> 2022-04-14T14:16:04.848Z  ntpd[26996]: adjusting local clock by 3.185755s
> 2022-04-14T14:17:40.286Z  ntpd[26996]: adjusting local clock by 3.575126s
> 2022-04-14T14:18:45.582Z  ntpd[26996]: adjusting local clock by 4.231518s
> 2022-04-14T14:22:27.618Z  ntpd[26996]: adjusting local clock by 4.231999s
> 2022-04-14T14:25:41.618Z  ntpd[26996]: adjusting local clock by 4.844904s
> 2022-04-14T14:29:58.888Z  ntpd[26996]: adjusting local clock by 4.451876s
> 2022-04-14T14:32:41.628Z  ntpd[26996]: adjusting local clock by 5.250357s
> 
> etc. No difference whether qemu-ga is used or not. No difference between
> passing through the real cpu type (i.e. cpu=host, Ryzen 5650G in this case)
> and passing through as "common KVM processor". The guest does detect and
> use pvclock(4).
> 
> $ sysctl kern.timecounter
> kern.timecounter.tick=1
> kern.timecounter.timestepwarnings=0
> kern.timecounter.hardware=pvclock0
> kern.timecounter.choice=i8254(0) pvclock0(1500) acpihpet0(1000) 
> acpitimer0(1000)
> 
> Anyone have ideas of things I could try that are less wrong than
> running rdate from cron? Thanks.

I have a -current built-a-week-ago guest on stock Debian KVM, no problems
with time-keeping. It picks acpihpet as timecounter instead of pvclock:

$ sysctl kern.timecounter 
kern.timecounter.tick=1
kern.timecounter.timestepwarnings=0
kern.timecounter.hardware=acpihpet0
kern.timecounter.choice=i8254(0) pvclock0(500) acpihpet0(1000) acpitimer0(1000)



Re: Latency and loss persist with iwm0 (Was Re: Latency with run0 interface)

2022-03-16 Thread Stefan Sperling
On Wed, Mar 16, 2022 at 03:58:59PM +0100, Stefan Sperling wrote:
> APs not showing up in the 5GHz band has always been a problem on
> Intel cards. It goes back to older drivers like iwn(4) or perhaps
> even ipw(4).

Oops, I meant wpi(4), not ipw(4) :)   (ipw is 11b only)



Re: Latency and loss persist with iwm0 (Was Re: Latency with run0 interface)

2022-03-16 Thread Stefan Sperling
On Wed, Mar 16, 2022 at 07:56:20AM -0500, rea...@catastrophe.net wrote:
> On Wed, Mar 16, 2022 at 10:11:50AM +0100, Stefan Sperling wrote:
> >Looks like a firwmare or driver issue to me.
> >
> >Sorry, without having a reproducible test case in front of me, there
> >is nothing I could do fix this from afar.
> 
> I mean, in fact it's 100% reproducible.
> 
> >You could try moving the AP to a different channel as a workaround.
> 
> I've already tried that and it doesn't solve the problem at all.
> 
> Thanks anyway. 

APs not showing up in the 5GHz band has always been a problem on
Intel cards. It goes back to older drivers like iwn(4) or perhaps
even ipw(4). In all cases I know of so far, repeating the scan
made the AP appear eventually. This is the first time I know of
where it never appears.

There is some firmware-specific behaviour involved that is mostly
beyond the driver's control, and even the little of what the driver
can do mostly eludes my understanding and is not well documented.

Because upper ranges of the 5GHz band are restricted, the Intel firmware
does not allow the driver to simply send a frame without having done some
internal checks first. I don't know how this really works. It might
involve listening on the channel for some time to see if a valid 802.11
frame is received before sending anything on a channel. While scanning
channels the firmware does not have a lot of time to listen on each of
them all.

Effectively this also means that all scans on 5GHz are passive, i.e.
the firmware will not send a probe request, it will only listen for
a beacon, which could be missed based on timing. Scans on 2GHz are
more reliable for this reason.

We run the firmware in the "world" regulatory domain. The Linux driver
will adapt the regdomain using various heuristics and perhaps open up
some channels in the 5GHz band which firmware is gating by default.
So perhaps that would help you.
However it is a lot of work to add this feature. Simply using the world
domain is easy and has never really been an issue.

None of this answers the question of why you are seeing 30% packet
loss on 2GHz, though. Is there really that much traffic on channel 1-11?
If other devices work, perhaps there is something wrong with your hardware
or antenna setup? I don't know what to suggest, just again pointing out
that there are configurations similar to yours that are known to work :-/
If you get a chance to try the device in a different RF environment to
see if it works there, that might already tell you something.



Re: Latency and loss persist with iwm0 (Was Re: Latency with run0 interface)

2022-03-16 Thread Stefan Sperling
On Tue, Mar 15, 2022 at 02:50:29PM -0500, rea...@catastrophe.net wrote:
> Ok, please see the following. The card is cleared of its monitor config then
> put onto channel 132 in debug mode.
> 
> # ifconfig iwm0 -chan
> # ifconfig iwm0 -mediaopt monitor
> # ifconfig iwm0
> iwm0: flags=8806 mtu 1500
> lladdr 80:19:34:ab:ab:ab
> index 5 priority 4 llprio 3
> groups: wlan
> media: IEEE802.11 autoselect mode 11n (HT-MCS0 mode 11n)
> status: no network
> ieee80211: nwid ""
> # ifconfig iwm0 chan 132
> # ifconfig iwm0 debug
> 
> # ifconfig iwm0
> iwm0: flags=8847 mtu 1500
>   lladdr 80:19:34:ab:ab:ab
>   index 5 priority 4 llprio 3
>   groups: wlan
>   media: IEEE802.11 autoselect mode 11n (HT-MCS0 mode 11n)
>   status: no network
>   ieee80211: nwid "" chan 132
> 
> # date  
> Mar 15 14:39:48 CDT 2022
> 
> # tail -f /var/log/messages
> Mar 15 14:39:50 admiralty /bsd: iwm0: SCAN -> SCAN
> Mar 15 14:39:54 admiralty /bsd: iwm0: end passive scan
> Mar 15 14:39:54 admiralty /bsd: iwm0: - 04:d4:c4:XX:ab:24   44!  +12 54M   
> ess  privacy!   no  "FOREIGN-NET-A"!
> Mar 15 14:39:54 admiralty /bsd: iwm0: - 3c:28:6d:XX:6d:dc   11!  +14 54M   
> ess  privacy!   no  "FOREIGN-NET-B"!
> Mar 15 14:39:54 admiralty /bsd: iwm0: - 3c:7c:3f:XX:99:a86!  +12 54M   
> ess  privacy!   no  "FOREIGN-NET-C"!
> Mar 15 14:39:54 admiralty /bsd: iwm0: - 60:45:cb:XX:99:c09!  +22 54M   
> ess  privacy!   no  "GJMD"!
> Mar 15 14:39:54 admiralty /bsd: iwm0: - 60:45:cb:XX:99:c4  165!  +24 54M   
> ess  privacy!   no  "GJMD_5G"!
> Mar 15 14:39:54 admiralty /bsd: iwm0: - 6a:db:f5:XX:c9:2e  165!  +29 54M   
> ess  privacy!   no  "DIRECT-As-FireTV_1353"!
> Mar 15 14:39:54 admiralty /bsd: iwm0: - 6c:70:9f:AA:BB:CC1!  +11 54M   
> ess  privacy!   no  "WIFI-NET"!
> Mar 15 14:39:54 admiralty /bsd: iwm0: - 70:4f:57:XX:0d:b39!  +16 54M   
> ess  privacy!   no  "Taffi"!
> Mar 15 14:39:54 admiralty /bsd: iwm0: - fc:15:b4:XX:78:1f   11!  +25 54M   
> ess  privacy!   no  "HP-Print-1F-ENVY 5530 series"!
> Mar 15 14:39:54 admiralty /bsd: iwm0: SCAN -> SCAN
> 
> Only WIFI-NET still comes in the scan results on channel 1. While I do see
> foreign networks on 5Ghz channels, nothing shows for the ssid WIFI-NET-5G
> 
> A linux machine connected to WIFI-NET-5G shows:
> 
> linux$ iwconfig wlan0
> wlan0 IEEE 802.11  ESSID:"WIFI-NET-5G"
>   Mode:Managed  Frequency:5.66 GHz  Access Point: 6C:70:9F:AA:BB:CD
>   Bit Rate=195 Mb/s   Tx-Power=31 dBm   
>   Retry short limit:7   RTS thr:off   Fragment thr:off
>   Power Management:on
>   Link Quality=41/70  Signal level=-69 dBm 
>   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>   Tx excessive retries:37  Invalid misc:0   Missed beacon:0
> 
> linux$ iwlist wlan0 channel | grep Current
>   Current Frequency:5.66 GHz (Channel 132)
> 
> 

Looks like a firwmare or driver issue to me.

Sorry, without having a reproducible test case in front of me, there
is nothing I could do fix this from afar.
You could try moving the AP to a different channel as a workaround.



Re: Latency and loss persist with iwm0 (Was Re: Latency with run0 interface)

2022-03-15 Thread Stefan Sperling
On Tue, Mar 15, 2022 at 09:09:57AM -0500, rea...@catastrophe.net wrote:
> Yes you did, and I greatly appreciate it. However, the interface won't
> join to anything once out of monitor mode.
> 
> # uname -a
> OpenBSD server.example.org 7.0 GENERIC.MP#5 amd64
> 
> # ifconfig iwm0 mediaopt monitor mode 11n
> # ifconfig iwm0 chan 132
> # ifconfig iwm0 up
> # ifconfig iwm0
> iwm0: flags=8843 mtu 1500
>   lladdr 80:19:34:ab:ab:ab
>   index 5 priority 4 llprio 3
>   groups: wlan
>   media: IEEE802.11 autoselect mode 11n monitor
>   status: active
>   ieee80211: nwid "" chan 132
 
> Next I'll try join the network using the 5Ghz ssid on channel 132
> 
> # ifconfig iwm0 -mediaopt monitor

Internally, the channel set for monitor mode is tracked in a different
variable than in the other modes (yet another thing that should probably
be fixed).

So try clearing and setting the channel again at this point.

> # ifconfig iwm0 nwid WIFI-NET-5G wpakey skcuserawmrifletni
> # ifconfig iwm0 192.168.1.8/24
> # ifconfig iwm0
> iwm0: flags=8843 mtu 1500
>   lladdr 80:19:34:ab:ab:ab
>   index 5 priority 4 llprio 3
>   groups: wlan
>   media: IEEE802.11 autoselect mode 11n (HT-MCS0 mode 11n)
>   status: no network
>   ieee80211: nwid WIFI-NET-5G chan 132 wpakey wpaprotos wpa2 wpaakms psk 
> wpaciphers ccmp wpagroupcipher ccmp
>   inet 192.168.1.8 netmask 0xff00 broadcast 192.168.1.255
> 
> At this point, the interface never leaves status of "no network".
> 
> I also tried with another network near me (to rule out it being an Apple
> Airport issue) and have the same issues.

Based on this I cannot tell why it does not manage to connect.

Please enable: ifconfig iwm0 debug

Now watch for scan results with: tail -f /var/log/messages
The scan result entries should show a ! next to attributes that did
not match and prevented an AP from being selected. And it should
print some messages about association frames being exchanged with an AP
that it is trying to use. With this information we might be able to tell
why it is not associating.



Re: Latency and loss persist with iwm0 (Was Re: Latency with run0 interface)

2022-03-15 Thread Stefan Sperling
On Tue, Mar 15, 2022 at 08:02:07AM -0500, rea...@catastrophe.net wrote:
> On Mon, Mar 14, 2022 at 11:37:15PM +0100, Stefan Sperling wrote:
> >In the implementation, the mode determines which channels are available,
> >not the other way around.
> >And for some reason your interface goes into a mode that only supports
> >2 GHz band channels.
> 
> >This should be fixed, when the user says "chan 132" ifconfig or the kernel
> >should figure out that the mode needs to be switched if it is incompatible
> >with the requested channel. It's one of those bugs that nobody ever runs
> >into unless they are debugging things.
> 
> Unfortunately it appears as though I've run into it. Is there any recourse
> to provide more useful debugging information to find the issue?

I already gave you a workaround:

ifconfig iwm0 mediaopt monitor mode 11n
ifconfig iwm0 chan 132



Re: Latency and loss persist with iwm0 (Was Re: Latency with run0 interface)

2022-03-14 Thread Stefan Sperling
On Mon, Mar 14, 2022 at 05:16:32PM -0500, rea...@catastrophe.net wrote:
> Trying to manually monitor channel 132, I get an error, SIOCS80211CHANNEL.
> 
> # ifconfig iwm0
> iwm0: flags=8802 mtu 1500
>   lladdr 80:19:34:ab:ab:ab
>   index 5 priority 4 llprio 3
>   groups: wlan
>   media: IEEE802.11 autoselect
>   status: no network
>   ieee80211: nwid ""
> # ifconfig iwm0 mediaopt monitor
> # echo $?
> 0
> # ifconfig iwm0 chan 132
> ifconfig: SIOCS80211CHANNEL: Invalid argument

The device should support this channel. This gives a list: ifconfig iwm0 chan

However, monitor mode is not very user-friendly.
Try to force it into 11n mode, then it should work:

ifconfig iwm0 mediaopt monitor mode 11n
ifconfig iwm0 chan 132

In the implementation, the mode determines which channels are available,
not the other way around.
And for some reason your interface goes into a mode that only supports
2 GHz band channels.
This should be fixed, when the user says "chan 132" ifconfig or the kernel
should figure out that the mode needs to be switched if it is incompatible
with the requested channel. It's one of those bugs that nobody ever runs
into unless they are debugging things.

> # dmesg|grep iwm
> iwm0 at pci5 dev 0 function 0 "Intel AC 7260" rev 0xc3, msi
> iwm0: hw rev 0x140, fw ver 17.3216344376.0, address 80:19:34:ab:ab:ab
> 
> Even after a clean reboot I can't bring the interface up in monitor mode
> and join anything other than channels 1-11.

That is expected.
You cannot use network in monitor mode at all, only listen to a channel.
In order to join a network, you need to disable monitor mode again first:
ifconfig iwm0 -mediaopt monitor -mode -chan



Re: Latency and loss persist with iwm0 (Was Re: Latency with run0 interface)

2022-03-14 Thread Stefan Sperling
On Mon, Mar 14, 2022 at 04:07:33PM -0500, rea...@catastrophe.net wrote:
> Just sitting around doing nothing I'm seeing 30% loss to my next hop.
> 
> # ifconfig iwm0
> iwm0: flags=808843 mtu 1500
>   lladdr 80:19:34:ab:ab:ab
>   index 5 priority 4 llprio 3
>   groups: wlan egress
>   media: IEEE802.11 autoselect (HT-MCS3 mode 11n)
>   status: active
>   ieee80211: nwid WIFI-NET chan 1 bssid 6c:70:9f:XX:XX:XX 52% wpakey 
> wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
>   inet 192.168.1.227 netmask 0xff00 broadcast 192.168.1.255
> # ping -qc 30 192.168.1.1
> PING 192.168.1.1 (192.168.1.1): 56 data bytes
> 
> --- 192.168.1.1 ping statistics ---
> 30 packets transmitted, 21 packets received, 30.0% packet loss
> round-trip min/avg/max/std-dev = 2.092/5.420/10.804/2.673 ms
> 
> 
> What exact model do you have of the 3160? Maybe I can try and source one
> and give it a try.

I doubt it would make a difference. This doesn't look like a hardware
defect, given that your run(4) device was also unhappy.

My guess would be that the channel is noisy. Try to move your AP to
another channel, like channel 6 or channel 11. And if your AP can use
the 5 GHz band (channel 36 and up) that might help a lot more.

To see what else is going on on channel 1 outside your wifi network,
you can use this:

ifconfig iwm0 mediaopt monitor
ifconfig iwm0 chan 1
ifconfig iwm0 up
tcpdump -n -i iwm0 -y IEEE802_11_RADIO

To go back to regular client mode:

ifconfig iwm0 -mediaopt monitor
ifconfig iwm0 -chan



Re: Latency and loss persist with iwm0 (Was Re: Latency with run0 interface)

2022-03-14 Thread Stefan Sperling
On Mon, Mar 14, 2022 at 03:05:00PM -0500, rea...@catastrophe.net wrote:
> On Mon, Mar 14, 2022 at 08:58:01PM +0100, Stefan Sperling wrote:
> >On Mon, Mar 14, 2022 at 02:34:29PM -0500, rea...@catastrophe.net wrote:
> >> Well, even after adding iwm0 I notice high latency and packet loss anywhere
> >> from 15-50%.  This occurs randomly when the device is either 2m, 10m, or 
> >> 30m
> >> away from the access point. I did testing to verify I'm seeing 65-80% 
> >> signal
> >> strength during some of the testing, but there's still loss even at that
> >> strength.
> >> 
> >> For now I'll hang an iogear GWU637 off em0 and bridge to the wireless net
> >> using that. Maybe things will get better with iwm(4) in the future.
> >
> >That is not expected.
> >The driver is working fine in general and connections should be stable.
> >
> >That said, I had a similar problem with a umb(4) device that worked
> >perfectly fine in a laptop, but had 20%-30% packet loss when I tried
> >to use it in an APU, and not just one APU but three of them (I tried
> >it an APU1, an APU2, and a different APU2; same issue in all of them).
> >
> >Try the card and the driver in a different device if you can, just to
> >check?
> 
> I tried in 2 APU4 devices and the same issue happens.
> 
> Unfortunately I've got no other hardware to test with at this time.

Sorry, not sure what could be wrong.

The closest equivalent to your setup I have here are a 3160
minipcie card (same as the 7260 but with only 1 Tx/Rx chain
each instead of 2, i.e. no MIMO), and an APU2.

I did a quick test with a snapshot I built 4 days ago.

iwm0 at pci1 dev 0 function 0 "Intel AC 3160" rev 0x83, msi
iwm0: hw rev 0x160, fw ver 17.3216344376.0, address b4:6d:83:2b:95:a0

I don't see any packet loss.
This is the 3160 sending to a host behind the AP with tcpbench:

Conn:   1 Mbps:  109.417 Peak Mbps:  109.425 Avg Mbps:  109.417
   11035   13544592  108.248  100.00%
Conn:   1 Mbps:  108.248 Peak Mbps:  109.425 Avg Mbps:  108.248
   12035   13674912  109.399  100.00%
Conn:   1 Mbps:  109.399 Peak Mbps:  109.425 Avg Mbps:  109.399
   13049   13732832  108.346  100.00%
Conn:   1 Mbps:  108.346 Peak Mbps:  109.425 Avg Mbps:  108.346
   14055   13685048  108.936  100.00%
Conn:   1 Mbps:  108.936 Peak Mbps:  109.425 Avg Mbps:  108.936
   15057   13638712  108.892  100.00%
Conn:   1 Mbps:  108.892 Peak Mbps:  109.425 Avg Mbps:  108.892
^C
--- kipo tcpbench statistics ---
194605408 bytes sent over 15.537 seconds
bandwidth min/avg/max/std-dev = 51.155/99.968/109.425/15.694 Mbps

# ifconfig iwm0
iwm0: flags=a48843

Re: Latency and loss persist with iwm0 (Was Re: Latency with run0 interface)

2022-03-14 Thread Stefan Sperling
On Mon, Mar 14, 2022 at 02:34:29PM -0500, rea...@catastrophe.net wrote:
> Well, even after adding iwm0 I notice high latency and packet loss anywhere
> from 15-50%.  This occurs randomly when the device is either 2m, 10m, or 30m
> away from the access point. I did testing to verify I'm seeing 65-80% signal
> strength during some of the testing, but there's still loss even at that
> strength.
> 
> For now I'll hang an iogear GWU637 off em0 and bridge to the wireless net
> using that. Maybe things will get better with iwm(4) in the future.

That is not expected.
The driver is working fine in general and connections should be stable.

That said, I had a similar problem with a umb(4) device that worked
perfectly fine in a laptop, but had 20%-30% packet loss when I tried
to use it in an APU, and not just one APU but three of them (I tried
it an APU1, an APU2, and a different APU2; same issue in all of them).

Try the card and the driver in a different device if you can, just to
check?



Re: Hardware for OpenBSD based access point

2022-03-14 Thread Stefan Sperling
On Mon, Mar 14, 2022 at 04:58:07AM +0100, Nicolas Goy wrote:
> I actually have an OpenWRT box (LTE SMS gateway, the LTE modem wasn't
> compatible with OpenBSD when I installed it), and yeah, it is very
> decent. I guess that would be a viable alternative.

It is possible to install OpenWRT on some Unify AP models to get rid of
the Java-based controller requirement, phoning home, etc.



Re: Latency with run0 interface

2022-03-12 Thread Stefan Sperling
On Fri, Mar 11, 2022 at 02:41:05PM -0600, rea...@catastrophe.net wrote:
> >If not, consider hunting down a mini PCIe iwm(4) 7260 card, or an
> >M.2 AX200 iwx(4) card with an adapter from M.2 to mini PCIe.
> >Both would need compatible pigtails and antennas as well.
> 
> Thanks, I'll get a 7260. Do the half mini cards have any problems vs.
> the full PCI-e cards? 

You'll just need a screw-on bracket to convert it to full size and
then it should fit into the slot just fine.



Re: Latency with run0 interface

2022-03-11 Thread Stefan Sperling
On Fri, Mar 11, 2022 at 10:57:56AM -0600, rea...@catastrophe.net wrote:
> I'm using a Panda Express USB WiFi dongle on a PC Engines apu4 machine.

This is a strange choice on an APU. Such dongles are really a last
resort, they tend to suffer from cooling issues and small antennas,
and OpenBSD only runs them in 11g mode rather than 11n mode.

Are your APU's minipci slots already populated?
If not, consider hunting down a mini PCIe iwm(4) 7260 card, or an
M.2 AX200 iwx(4) card with an adapter from M.2 to mini PCIe.
Both would need compatible pigtails and antennas as well.

The bwfm(4) driver also supports M.2 cards which can work in an APU
with an adapter.

This would cost a bit more than a USB dongle but it can turn an
APU into a very decent wifi client (easily 100 Mbit/s or more
with an 11n-capable AP).



Re: student contributor inquiry

2022-01-29 Thread Stefan Sperling
On Sat, Jan 29, 2022 at 02:28:59AM +, jkinne...@yahoo.ca wrote:
> Hello,
> 
> I would like to know if the OpenBSD project has any supports for a student 
> that would like to spend a semester contributing to an open source project?  
> I am coming from an arts and long time Linux user background and would like 
> to spend time learning a proper Unix as part of a projects based self study 
> period at university.  Is this something that the OpenBSD community has any 
> particular opportunities for?
> 
> Thank you for any thoughts, ideas, or direction.
> 
> Kindest Regards,
> 
> Jason
> 
> 

Hi Jason,

I made my first larger contributions to OpenBSD during a similar project
at university. What worked for me was to identify components of the system
that were related to the subject of my studies (computer networking).
After taking a closer look at these components I came up with some project
ideas, and then directly asked developers who appeared to be involved in
those areas about the feasibility of my ideas.

I had a time window of about 6 months for my project, so I was able to
dedicate a lot of time to it. I ended up working on ospf6d which was still
in early development at the time and in need of someone with time to push
it further.

Our backgrounds are very different, I was already deep in my CS studies.
You will already need to know C programming and/or shell scripting to
make code contributions. You don't need to be an expert already, but you
should be fairly advanced and able to understand feedback from experts.
Otherwise, you could contribute in other ways such as improving
documentation, help with porting existing programs (this can be relatively
easy to do if you already know how Linux packaging works), or by testing
patches that other people have in progress.

Hope this helps,
Stefan



Re: AX210 wifi

2022-01-17 Thread Stefan Sperling
On Sun, Jan 16, 2022 at 02:34:54PM -0800, Chris Cappuccio wrote:
> holy crap, rather than maintain the drivers and net80211 layer, they are just
> building compat for the linux version?

Yes. Any complex problem can be solved by adding another layer
of indirection ;)

I first heard of this idea at eurobsdcon in norway:
https://www.youtube.com/watch?v=8N0IL8APCHg=1943s



Re: full disk encryption with keydisk

2021-12-30 Thread Stefan Sperling
On Wed, Dec 29, 2021 at 05:22:19PM -0500, openbsd-m...@pyr3x.com wrote:
> Hello,
> 
> I'm using full disk encryption via the softraid subsystem and bioctl with a
> keydisk. I have a second drive that I'm backing up the root filesystem to
> via ROOTBACKUP=1 and the proper fstab entry.
> 
> I'd like to be able to reuse the same keydisk to decrypt the second drive.
> It appears there is no way to inform bioctl to reuse a correctly formatted
> keydisk, so it overwrites it each time. Right now I've opted to use a
> passfile for the second drive and confirmed I could boot to it by entering
> the passphrase via 'boot sr1a:/bsd -a' -- but I'd prefer to simply let it
> pickup the keydisk. Is there something I'm missing?

Two different crypto volumes cannot use the same RAID type disklabel
slice as a keydisk.

However, you can create two distinct RAID type disklabel slices on your
key disk device (1MB per slice should be sufficient), and then pass one
of each of those slices to bioctl -k when you create your two crypto volumes.
This way, a single physical disk device will be able to unlock both volumes.



Re: "run0: missing endpoint" on OpenBSD 7.0

2021-12-17 Thread Stefan Sperling
On Fri, Dec 17, 2021 at 02:14:31PM -0700, Jeff Ross wrote:
> Hi all,
> 
> Trying to replace an rsu usb wifi adapter with one that is a little more
> resilient because the rsu locks up about 4 or 5 times a day and it takes a
> reboot to get it to come back.
> 
> Full dmesg follows but on both this amd64 computer and a rpi 3B+ the result
> is the same:
> 
> run0 at uhub0 port 4 configuration 1 interface 0 "Ralink Technology RT2870"
> rev 2.00/0.01 addr 6
> run0: missing endpoint
> 
> And the run0 will not go any farther.
> 
> I hate to do this but with Ubuntu 20.04 on an OdroidN2 it works perfectly:

Looks like the USB configuration of your particular device
is not recognized by our driver yet.

Please run pkg_add usbutils and send the output of lsusb -v.



Re: DNS lookup fails and iwm0 fatal firmware errors using OpenBSD 7.0

2021-12-14 Thread Stefan Sperling
On Tue, Dec 14, 2021 at 12:49:14PM +, Dave Turner wrote:
> I have searched the web and tried various things but so far nothing
> fixes it.

This should help: https://marc.info/?l=openbsd-bugs=163459084214897=2



Re: RTL8852AE wifi driver

2021-11-20 Thread Stefan Sperling
On Sat, Nov 20, 2021 at 04:04:25PM +, Patrick Harper wrote:
> You need to get the authors to change the license to an acceptable one 
> first, as GPL won't cut it. https://www.openbsd.org/policy.html

The rtw89 driver is already dual-licensed as GPL/BSD via:
SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause

So there is no licensing issue here.



Re: U-blox MPCI-L210 LTE modem: cdce(4) unable to get the MAC address of the device

2021-11-15 Thread Stefan Sperling
On Sun, Nov 14, 2021 at 10:40:28PM +0100, na...@poczta.fm wrote:
> Hi misc@,
> 
> While testing the U-blox MPCI-L210 LTE modem on OpenBSD -current 
> (the modem is attached as a cdce(4) device, the router mode is enabled; 
> other modes are also available), I noticed that the automatic configuration 
> via DHCP works correctly, but the MAC address assigned to the corresponding 
> cdce0 network interface is different from the MAC address reported by 
> lsusb -v. Unfortunately, due to this mismatch, incoming Ethernet frames 
> having the actual MAC address of the device set as the destination address 
> in the header are dropped by the kernel in the ether_input() function 
> (/src/sys/net/if_ethersubr.c).
> 
> Based on an analysis of the source code (/sys/dev/usb/if_cdce.c) and the 
> results of the subsequent experiments, I was able to confirm that the cdce 
> driver is unable to get the MAC address of the device (in particular, 
> the usbd_get_string_desc() function returns USBD_STALLED instead of 
> USBD_NORMAL_COMPLETION), and as a result, a semi-random fake Ethernet 
> address is set:
> 
> -
> 306  if (!ethd || usbd_get_string_desc(sc->cdce_udev, ethd->iMacAddress, 0,
> 307  _str, )) {
> 308  ether_fakeaddr(ifp);// < Set a semi-random MAC address
> 309  } else {
> -

Can you find out what happens on Linux?

Their cdc_ether driver seems to be doing exactly the same thing. So with
this driver you would also end up with a random MAC if the device fails
to respond to a mac address query. In this case I have no idea what else
could be done apart from using the workaround you have already found.

But Linux has more CDC sub-drivers than we do, and runs some devices in
specialized modes.
Perhaps Linux performs a mode switch and uses a different driver for e.g.
MBIM mode? If that is the case then we could change our drivers to try to
switch this device into a mode where it works better.



Re: iwm stopped working on 7.0 after installing patches 001,002,003

2021-11-03 Thread Stefan Sperling
On Wed, Nov 03, 2021 at 08:34:19AM -0600, Theo de Raadt wrote:
> I do not think it is the errata, because they are completely unrelated
> to 802.11 drivers or stack.  You can look at the errata closer and
> realize it has nothing to do with wifi.
> 
> I suspect your firmware was updated.  Or you changed something else.
> 
> 
> Doros Eracledes  wrote:
> 
> > Thanks Stefan, I did try booting the snapshot bsd.rd kernel but got an
> > error about failing to load firmware, see attached screenshot.

Testing with bsd.rd is tricky because you will need to mount your
installed rootfs at /mnt before firmware can be loaded. The ramdisk
kernel does not carry intel wifi firmware files.

So please trying booting bsd.mp (.mp, not .rd) instead. You should
end up in your installed 7.0 system. A new kernel with old userland
is technically not a supported system configuration but it should be
good enough to confirm whether wifi is working at all, and you can
go back to your reguler kernel afterwards.

You could also upgrade your system to a -current snapshot using
the bsd.rd kernel you have. But then there is no way back to 7.0.

FWIW, my 9560 device seems to be working just fine in -current.



Re: iwm stopped working on 7.0 after installing patches 001,002,003

2021-11-03 Thread Stefan Sperling
On Wed, Nov 03, 2021 at 03:36:38PM +0200, Doros Eracledes wrote:
> Hi,
> 
> my iwm0 on my Lenovo T490 stopped working right after installing 7.0
> patches 001,002 and 003 and rebooting. I "takes" an ip from the router but I
> can't ping the router.
> 
> I then tried with a USB urtwn and it worked fine, I also uninstalled the
> firmware and reinstalled it and rebooted but no change.
> 
> Thanks Doros

Could you please give a -current kernel a try to see whether this
issue has been fixed since? Temporarily booting into a bsd.mp image
from the latest snapshot should be enough for testing purposes.
You do not need to upgrade the entire system if you do not want to.



Re: OpenBSD as wireless access point

2021-10-31 Thread Stefan Sperling
On Sun, Oct 31, 2021 at 11:36:21PM +0530, rahul deshmukh wrote:
> Hi Team,
> I have configured OpenBSD as wireless access point but somehow i am unable
> to connect to access point from mobile or other clients. below is my config.
> 
> myhost$ cat /etc/hostname.ral0
> 
> 
> media autoselect mode 11b mediaopt hostap chan 11

Why mode 11b?  Try 11g, or 11a with a channel >= 36.



Re: Sony UWA-BR100 patch to recognize AR9280+AR7010 Atheros based USB card

2021-10-31 Thread Stefan Sperling
On Sun, Oct 24, 2021 at 03:01:29PM +, Martin wrote:
> Patch has been updated to use correct files and tested on a live system. 
> Please add it to tree.
> 
> Thanks.

Committed now. Thank you!  Sorry it took so long.



Re: Samsung SSD X5 with OpenBSD - possible ?

2021-10-25 Thread Stefan Sperling
On Mon, Oct 25, 2021 at 05:45:22PM +, Laura Smith wrote:
> I'm struggling a bit as to what I need to do next here.
> 
> Any time in the past I've connected a USB stick etc. to OpenBSD, everything 
> happened automagically in terms of recognition and assigning a /dev/sd.
> 
> However this time, its different.  This is the only line that appears in 
> dmesg when I plug it in:
> 
> ugen0 at uhub0 port 4 "SAMSUNG ELECTRONICS CO., LTD Portable SSD X5" rev 
> 2.01/4.45 addr 2
> 
> sysctl hw.disknames remains unchanged
> 
> Any ideas ?
> 

I would guess that no driver is attaching because this drive requires
Thunderbolt 3 rather than USB 3 (both use a USB-C type connector).



Re: Thinkpad X1 Carbon Gen 7 WiFi connection issue

2021-10-25 Thread Stefan Sperling
On Mon, Oct 25, 2021 at 03:57:53PM +0900, Sardor Muminov wrote:
> Hello developers,
> 
> I own one of the Thinkpad X1 Carbon Gen 7 series laptops.
> I have installed OpenBSD 7.0 and couldn't get the wireless connection to
> work.
> 
> Below is a link to the dmesg[1] and pcidump[2] output.
> 
> 1.
> https://0bin.net/paste/pNBrVw-L#7eWENjA8U41mikVDnCgUsJensq+mWbRzpOuEtLD8usQ
> 2.
> https://0bin.net/paste/BCS7i7tw#-T5l1bFgNh3Q6eOb6R5sSOi57bEpFralPd5v/Hv1vdF
> 
> I have checked Joshua's blog post, but it seems I have a newer version of
> the WiFi chipset (Intel Wi-Fi 6 AX201).
> 
> Is there any possibility for me to get this issue resolved?
> 
> Thanks in advance,
> Sardor
> 

Can you please boot linux on this machine and tell me which firmware file
the linux iwlwifi driver is loading? In theory it is possible to figure
it out by reading the linux driver. In practice Intel's device matching
code is complicated to follow because they have workarounds layered on
top of more workarounds. The best I could do is make a blind guess, and
such guessing could needlessy waste some of your time and my time.
Thanks.



Re: USB athn0 issue in AP mode (AR9280+AR7010) no DHCP leases to modern portable devices

2021-10-23 Thread Stefan Sperling
On Fri, Oct 22, 2021 at 06:53:17PM +, Martin wrote:
> Hi there!
> 
> I have an issue with athn USB stick with modern wifi devices like Android 
> phones etc.
> 
> I've set up athn0 as previous athn miniPCI-e cards (/etc/hostname.athn0, 
> /etc/dhcpd.conf, /etc/pf.conf). No IP address given by OpenBSD7.0amd64 host's 
> DHCP for certain device once client has been connected to AP based on athn 
> USB stick.
> 
> Tested only with portable devices, not PCs currently.
> 
> Looking forward to resolve this!
> 
> Martin
> 
> 
> 

No idea, sorry.



Re: Sony UWA-BR100 patch to recognize AR9280+AR7010 Atheros based USB card

2021-10-23 Thread Stefan Sperling
On Fri, Oct 22, 2021 at 07:02:20PM +, Martin wrote:
> Hi Stefan,
> 
> Dev. patches to implement into source tree to recognize automatically Sony 
> UWA-BR100 devices based on AR9280+AR7010.

This patch is changing the wrong files.
It should change the files 'usbdevs' and if_athn_usb.c only.

usbdevs.h is a generated file, it should not be patched.
It can be re-generated by running 'make' in the sys/dev/usb directory.

> 
> --- if_athn_usb.c.origTue Jun  8 15:29:31 2021
> +++ if_athn_usb.c Tue Jun  8 15:34:11 2021
> @@ -91,6 +91,8 @@
>  ATHN_USB_FLAG_AR7010 },
>   {{ USB_VENDOR_PANASONIC, USB_PRODUCT_PANASONIC_N5HBZ055 },
>  ATHN_USB_FLAG_AR7010 },
> + {{ USB_VENDOR_MELCO, USB_PRODUCT_MELCO_UWABR100 },
> +ATHN_USB_FLAG_AR7010 },
>   {{ USB_VENDOR_VIA, USB_PRODUCT_VIA_AR9271 }}
>  };
>  #define athn_usb_lookup(v, p)\
> 
> --- usbdevs.h.origTue Jun  1 09:40:48 2021
> +++ usbdevs.h Tue Jun  8 15:30:51 2021
> @@ -3077,6 +3077,7 @@
>  #define  USB_PRODUCT_MELCO_WLIUCGNHP 0x0158  /* WLI-UC-GNHP 
> */
>  #define  USB_PRODUCT_MELCO_WLIUCGN   0x015d  /* WLI-UC-GN */
>  #define  USB_PRODUCT_MELCO_WLIUCG301N0x016f  /* WLI-UC-G301N 
> */
> +#define  USB_PRODUCT_MELCO_UWABR100  0x017f  /* SONY 
> UWA-BR100 */
>  #define  USB_PRODUCT_MELCO_WLIUCGNM  0x01a2  /* WLI-UC-GNM */
>  #define  USB_PRODUCT_MELCO_WLIUCGNM2 0x01ee  /* WLI-UC-GNM2 
> */
> 
> 
> Thanks for your attention.
> 
> Martin
> 
> 



Re: lenovo B50-30 wifi

2021-10-17 Thread Stefan Sperling
On Sun, Oct 17, 2021 at 07:14:59PM +0200, Jan Stary wrote:
> Right. I have had this problem with some Thinkpads. According to
> https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles_pdf/b40_b50_rn_eu.pdf
> the whitelist for this Lenovo B50-30 is
> 
>   • 3160NGW
>   • BCM943142Y
>   • QCNFA335
>   • RTL8723BE
>   • 7260NGW
>   • BCM94352Z
> 
> Would people recommend any of these specificaly? I have only used
> the Intel AC 7260 (mini-pci) before in some other Thinkpads

Get a 7260NGW. If you cannot find one then the 3160NGW would also work.
Both are iwm(4). Note that these cards exist in half-size minipcie form
factor and in M.2 form factor. Make sure to get the M.2 version. Which is
probably much more rare than the half-size minipcie version, I would guess.



Re: lenovo B50-30 wifi

2021-10-17 Thread Stefan Sperling
On Sun, Oct 17, 2021 at 05:21:24PM +0200, Stefan Sperling wrote:
> Most iwm(4) cards (7265 up to 9560), and iwx(4) AX200 (not the AX201,
> which is cnvi instead of M.2 but looks the same).

Correction; The iwm 9560 uses cvni as well and won't work.

All this applies only if there isn't some BIOS whitelist of
allowed wifi cards in this machine...



Re: lenovo B50-30 wifi

2021-10-17 Thread Stefan Sperling
On Sun, Oct 17, 2021 at 05:05:19PM +0200, Jan Stary wrote:
> This is current/amd64 on a Lenovo B50-30 (full dmesg below).
> Everything seems to run fine, except the wifi is unsupported.
> 
> "Atheros AR9565" rev 0x01 at pci4 dev 0 function 0 not configured
> ugen1 at uhub1 port 4 "Atheros Communications product 0x3004" rev 1.10/0.01 
> addr 5
> 
> I suppose it's one of those a wifi/bt combos usual in laptops;
> see e.g. https://www.ebay.com/itm/274629920857 - that's what I have.
> I haven't seen the form factor before; it's neither a full-size
> nor a half-size mini-pcie card.

Looks like an M.2 card: https://en.wikipedia.org/wiki/M.2

> Are there any wifi cards of this form factor supported by OpenBSD?

Most iwm(4) cards (7265 up to 9560), and iwx(4) AX200 (not the AX201,
which is cnvi instead of M.2 but looks the same).



Re: athn AP

2021-10-16 Thread Stefan Sperling
On Sat, Oct 16, 2021 at 01:40:55PM +0200, Jan Stary wrote:
> Would people now recommend running an AP "natively",
> i.e. a wifi card (plus the anthenas) on and OpenBSD box
> over running wifi over a dedicated device?

Not if you want a modern 11ac/ax AP. There is no driver which supports
hostap and matches off-the-shell APs in terms of stability and speed.

athn(4) mostly works but is slow due to lack of proper 11n support
and has several unresolved performance bugs. And it still lacks
support for 3-antenna devices.

bwfm(4) is fast (11ac) but not yet as stable as athn(4).

If all you need is 11a/g then ral(4) and ath(4) are good options.



Re: Keeping a personal ports branch

2021-10-15 Thread Stefan Sperling
On Fri, Oct 15, 2021 at 10:25:17AM -, Rubén Llorente wrote:
> Hi there!
> 
> I am wondering how does people around here keep local branches of the ports
> tree for personal use.
> 
> The reason I am asking is because I keep some patched ports which are suited
> to solve my problems, but not suited (or useful) for submission to the
> official ports tree. Ideally I would upgrade my personal ports tree alongisde
> the official one.
> 
> I suppose I could cvs import every -RELEASE of the ports into my own cvs
> repository, but ideally I would rather have something more automated.
> Besides, I am curious as to how people is doing it.

You can use the conversion of the CVS ports repository to Git and
manage your local branches in a private repository clone. Conversion
from CVS to Git is already automated so you don't have to take care
of this yourself. The repository you need is published on github:
  https://github.com/openbsd/ports.git

Two tools from ports can work on this repository, devel/git and devel/got.
If you already like Git, then use it.

If you don't enjoy using Git, give Got a try:
  pkg_add got
  man got (read the EXAMPLES section first if you don't know where to start)
Got doesn't support HTTP yet. You can add an SSH key to your github profile
and then clone the repository over SSH instead:
  got clone ssh://g...@github.com/openbsd/ports.git



Re: Experience using httpd in production on busy machines?

2021-08-26 Thread Stefan Sperling
On Thu, Aug 26, 2021 at 06:20:08AM -0300, Crystal Kolipe wrote:
> On Thu, Aug 26, 2021 at 02:47:40AM +, iio7 wrote:
> > Any caveats to look out for?
> 
> There is an issue with httpd and large file uploads, ( > ~ 600 Mb), which was 
> introduced sometime after OpenBSD 6.1.
> 
> We had a system handling such large file uploads via http, (which is probably 
> not a typical use case), and it worked fine whilst it was running OpenBSD 
> 6.1.  When OpenBSD 6.6 was released we did a fresh installation and found 
> that uploads over about 600 Mb would randomly abort.  Since by this time the 
> system had fallen into disuse anyway, as far as I know nobody here bothered 
> to investigate further, but testing now on an OpenBSD 6.9 installation, I can 
> see that the bug still exists.
> 

If your test on 6.9 involves a handoff to fcgi (e.g. nextcloud) then
please try again with a server running -current. There was a related
bug fixed in May after 6.9 was branched.



Re: Unexpected pf behavior for DHCP traffic?

2021-08-19 Thread Stefan Sperling
On Thu, Aug 19, 2021 at 06:42:25PM +0100, Étienne wrote:
> On 31/07/2021 19:27, Stefan Sperling wrote:
> > On Sat, Jul 31, 2021 at 07:02:35PM +0100, Étienne wrote:
> > > On 30/07/2021 04:37, Theo de Raadt wrote:
> > > > dhcpleased (and a few other daemons) use bpf, thus see raw packets
> > > > from the wire before pf can block them.  Most daemons of this type
> > > > also use bpf to send packets, and pf doesn't see these either
> > > Does that prevent dhcpd from listening on any virtual interface? I'm 
> > > trying
> > > to have it listen for requests on a vether in a bridge, and that fails (or
> > > I'm making a mistake).
> > 
> > It should work, unless are running dhclient/dhcpleased on the same machine,
> > because the bpf filter will eat DHCP-related packets. You'll know whether
> > this affects you by checking whether dhcpd starts working when you kill the
> > DHCP client.
> 
> Thanks for your help, Stefan, and sorry for coming back so late on that.
> Despite the tip, I'm afraid it doesn't  work.
> 
> I have two Ubiquiti EdgerouterLite running 6.9, these boxes have 3
> interfaces cnmac0, cnmac1 and cnmac2. I bridge cnmac0 and cnmac1, and I
> connect cnmac0 on both boxes to one switch, and cnmac1 on both boxes to
> another switch. I turn RSTP on all these interfaces and on the switches, add
> a vether0 with an IP address (in 172.16.0.0/16) in bridge0 on either box,
> and I have connectivity.
> 
> I also configure an IP address on cnmac2 (in 192.168.1.0/24). Then I
> configure dhcpd to listen on cnmac2 and on vether0:
> 
> dhcpd_flags=-y vether0 -Y vether0 vether0 cnmac2
> 
> With this setup, I see DHCP leases added in the 192.168.1.0 range, but none
> in the 172.16.0.0 range. Moreover, I see DHCP requests when running tcpdump
> on bridge0, but not on vether0. So I'm not sure what's preventing it to
> work.
> 
> My configuration files content:
> 
> % cat /etc/hostname.cnmac0
> up
> % cat /etc/hostname.cnmac1
> up
> % cat /etc/hostname.cnmac2
> inet 192.168.1.4 255.255.255.0 NONE
> !route add 0.0.0.0/0 192.168.1.254
> inet6 autoconf
> up
> % cat /etc/hostname.vether0
> lladdr fe:e1:ba:d0:be:d3
> inet 172.16.0.4 255.255.255.0
> up
> % cat /etc/hostname.bridge0
> add cnmac0
> stp cnmac0
> add cnmac1
> stp cnmac1
> add vether0
> maxaddr 1000
> timeout 40
> up
> % cat /etc/dhcpd.conf
> 
> option  domain-name-servers 192.168.1.254;
> default-lease-time 14400;
> max-lease-time 86400;
> 
> subnet 192.168.1.0 netmask 255.255.255.0 {
>   option routers 192.168.1.254;
> 
>   range 192.168.1.16 192.168.1.126;
> }
> 
> subnet 172.16.0.0 netmask 255.255.255.0 {
>   option routers 172.16.0.1;
> 
>   range 172.16.0.16 172.16.0.126;
> }
> 
> Running tcpdump shows this:
> 
> % doas tcpdump -ve -i bridge0 "port 67 or port 68"
> tcpdump: listening on bridge0, link-type EN10MB
> 19:16:57.596572 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
> 255.255.255.255.bootps:  xid:0x10e264ab secs:1120 [|bootp] (ttl 64, id 0,
> len 328)
> 19:17:00.597025 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
> 255.255.255.255.bootps:  xid:0x10e264ab secs:1123 [|bootp] (ttl 64, id 0,
> len 328)
> 19:17:03.600246 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
> 255.255.255.255.bootps:  xid:0x10e264ab secs:1126 [|bootp] (ttl 64, id 0,
> len 328)
> […]
> 19:17:42.630441 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
> 255.255.255.255.bootps:  xid:0x10e264ab secs:1165 [|bootp] (ttl 64, id 0,
> len 328)
> ^C
> 74 packets received by filter
> 0 packets dropped by kernel
> % doas tcpdump -ve -i vether0 "port 67 or port 68"
> tcpdump: listening on vether0, link-type EN10MB
> ^C
> 1320 packets received by filter
> 0 packets dropped by kernel
> 
> Any idea?

I suspect the packets towards vether0 are being dropped by pf.
What does your pf.conf look like?

Do you see anything related in tcpdump -n -i pflog0, provided you've
using 'log' statements on your block rules in pf.conf?

Does adding this as the final rule help?
pass on bridge0 no state



Re: Unexpected pf behavior for DHCP traffic?

2021-07-31 Thread Stefan Sperling
On Sat, Jul 31, 2021 at 07:02:35PM +0100, Étienne wrote:
> On 30/07/2021 04:37, Theo de Raadt wrote:
> > dhcpleased (and a few other daemons) use bpf, thus see raw packets
> > from the wire before pf can block them.  Most daemons of this type
> > also use bpf to send packets, and pf doesn't see these either
> Does that prevent dhcpd from listening on any virtual interface? I'm trying
> to have it listen for requests on a vether in a bridge, and that fails (or
> I'm making a mistake).

It should work, unless are running dhclient/dhcpleased on the same machine,
because the bpf filter will eat DHCP-related packets. You'll know whether
this affects you by checking whether dhcpd starts working when you kill the
DHCP client.



Re: Unexpected pf behavior for DHCP traffic?

2021-07-30 Thread Stefan Sperling
On Fri, Jul 30, 2021 at 04:59:03AM +, beebeet...@posteo.de wrote:
> Thanks Theo for the answer!
> 
> I'm still having difficulty wrapping my head around it.
> 
> I have two packets: DHCPREQUEST and DHCPACK
> {timestamp} {my_ip}.68 > {ip1}.67: xid:0xfe51c9a3 [|bootp]
> {timestamp} {ip2}.67 > {my_ip}.68: xid:0xfe51c9a3 Y:{my_ip} G:{ip1}[|bootp]
> 
> I get that tcpdump taps to bpf so it can see both packets.
> 
> And my understanding of your answer is that pf doesn't see the
> first packet (DHCPREQUEST) since it's being sent using bpf.
> 
> The second packet (DHCPACK) -- although dhcpleased has unfiltered
> access to -- is eventually visible to pf, thus will be blocked by
> pf and should show up on the pflog0 interface as per the following
> rule:
> 
> > block drop in log (all) on $ext_if inet proto udp \
> > from port 67 to port 68
> 
> However, it seems that nothing appears on pflog0 in my case, which
> is what I still can't comprehend.
> 
> Am I missing something here?

BPF filters have the ability to drop packets before pf sees them.
dhclient/dhcpleased make use of this feature, and they match any UDP
packets using DHCP-related ports.



Re: Why demotion counter for group carp is set to 33 on boot?

2021-07-14 Thread Stefan Sperling
On Wed, Jul 14, 2021 at 11:38:15AM +0200, Tom K wrote:
> 
> > > but why? If I reboot the other node, the system become MASTER.
> > 
> > That is because the other system stops sending carp announcements
> > when you reboot it. This is unrelated to the demote counter. The demote
> > counter only matters as long as another carp MASTER remains visible.
> > A forced failover like this could break active connections.
> > 
> > The pfsync interfaces adds 32 to the carp demote counter when it comes
> > up,
> > and it removes 32 from the demote counter once it has obtained an
> > up-to-date
> > copy of the state table, which can take some time.
> > 
> > This prevents the box from becoming MASTER while it may not yet know
> > about all the currently active connections.
> > 
> 
> But why the 1st system is switchback to BACKUP if the 2nd system is Up
> again? Normaly 1st should stay MASTER, because at this time, the 1st one
> have the most recent state table which should be now send to the 2nd one.
> Yes, it's because of the higher demotioncount then the 2nd system, but if
> the 1st one standalone, it should self demoted to 0/1 bei pfsync because
> there is no other system?
> 
> I wait more then an hour, but the system is still on 33. So it seems the
> state table is never synced completly, but if I compare both with "pfctl -s
> state" they look are in sync - strange.
> 
> I never had this issue and we use a lot of cluster setups like these in the
> past.

Yes that doesn't seem right.
If you have the net.inet.carp.preempt sysctl set then the machine with a
lower adskew value should move into BACKUP, provided the demote count is
equal. But if the demote count is not equal then of course the machine
with a higher demote count will remain in BACKUP state.

If the demote count never drops then perhaps pfsync traffic isn't passing
properly?



Re: Why demotion counter for group carp is set to 33 on boot?

2021-07-14 Thread Stefan Sperling
On Wed, Jul 14, 2021 at 08:28:09AM +0200, Tom K wrote:
> JP,
> 
> but why? If I reboot the other node, the system become MASTER.

That is because the other system stops sending carp announcements
when you reboot it. This is unrelated to the demote counter. The demote
counter only matters as long as another carp MASTER remains visible.
A forced failover like this could break active connections.

> At this time,
> no other system has more recent rule states and the 2nd system comes back,
> the 1st will fall to BACKUP although it has no adskew settings and
> demotecount still on 33.

> I'm very confused about this issue.

The pfsync interfaces adds 32 to the carp demote counter when it comes up,
and it removes 32 from the demote counter once it has obtained an up-to-date
copy of the state table, which can take some time.

This prevents the box from becoming MASTER while it may not yet know
about all the currently active connections.

Just don't worry about it. It is supposed to happen this way.



Re: apu2 and Atheros WLE600VX not working

2021-06-30 Thread Stefan Sperling
On Wed, Jun 30, 2021 at 07:45:13AM -0400, George wrote:
> Hi thanks for the reply! How is the performance on the 200nx are you using
> it as an access point i.e. router? How many antennas?

There is currently no way to run an AP on OpenBSD if you require performance
levels comparable to commercially available access points.

Regarding athn(4) in particular, there is no support for Tx aggregation and
there are unresolved bugs which prevent Tx rates at the upper end from working.
You can expect about 20 Mbit/s top, most likely less than that.
But it is fairly stable. If performance isn't your main concern it can be fine.

athn(4) only supports 2 antenna cards. Cards with 3 anntennas don't work yet.
If you can only connect one antenna you need to run this command to prevent
packet loss: ifconfig athn0 nwflag nomimo



Re: Latest iwm firmware disconnects and requires a /bin/sh /etc/netstart iwm0 to reconnect

2021-06-19 Thread Stefan Sperling
On Sat, Jun 19, 2021 at 11:46:44AM +0200, Stefan Sperling wrote:
> On Fri, Jun 18, 2021 at 03:54:33PM -0500, John Batteen wrote:
> > Possibly initiated by moving to a new access point.  Thinkpad T550, Intel 
> > AC 7265
> > 
> > /etc/hostname.iwm0:
> > nwid mynet wpakey mykey
> > dhcp
> > 
> > iwm0: hw rev 0x210, fw ver 17.3216344376.0, address 18:5e:0f:ea:ff:c4
> 
> This isn't the latest firmware yet, it's the firmware we've been using
> for a long time.
> 
> > iwm0: Could not empty Tx queues (error 35)
> 
> This is a driver-side issue which was recently introduced. The driver
> treats this situation as an error while it is in fact a legitimate
> situation that could be handled more gracefully.
> 
> I have a fix as part of a larger patch which isn't ready yet.
> If this error bothers you I can commit my fix in isolation. But it's
> really just a cosmetic issue since the driver recovers from it.

And if you need any help with the "disconnect" issue, your report
lacks details:

Enable 'ifconfig iwm0 debug', trigger the issue again, and there
should now be a lot more context info in the dmesg buffer which
you can share.

You mentioned switching access points. Which models were involved (old
and new)?



Re: Latest iwm firmware disconnects and requires a /bin/sh /etc/netstart iwm0 to reconnect

2021-06-19 Thread Stefan Sperling
On Fri, Jun 18, 2021 at 03:54:33PM -0500, John Batteen wrote:
> Possibly initiated by moving to a new access point.  Thinkpad T550, Intel AC 
> 7265
> 
> /etc/hostname.iwm0:
> nwid mynet wpakey mykey
> dhcp
> 
> iwm0: hw rev 0x210, fw ver 17.3216344376.0, address 18:5e:0f:ea:ff:c4

This isn't the latest firmware yet, it's the firmware we've been using
for a long time.

> iwm0: Could not empty Tx queues (error 35)

This is a driver-side issue which was recently introduced. The driver
treats this situation as an error while it is in fact a legitimate
situation that could be handled more gracefully.

I have a fix as part of a larger patch which isn't ready yet.
If this error bothers you I can commit my fix in isolation. But it's
really just a cosmetic issue since the driver recovers from it.



Re: iwm0: fatal firmware error

2021-05-24 Thread Stefan Sperling
On Mon, May 24, 2021 at 02:35:02PM +0200, Marco Scholz wrote:
> Hello.
> My laptop (Lenovo Thinkpad T495s AMD Ryzen) reports an iwm0 fatal
> firmware error. I'm running 6.9 #29.
> System gets quite hot, systat shows 40-50% interrupt while idling.
> Networking works fine.
> 
> Anybody else has this issue?

This looks like a known issue. I hope to get it fixed eventually but for
now there other changes we need to make with higher priority (i.e. we
need fimware updates for fragattack security fixes).



Re: pf ipv6 source-routing 6.9

2021-05-10 Thread Stefan Sperling
On Mon, May 10, 2021 at 12:05:16PM +0200, Bastien Durel wrote:
> Referencing fe80::520f:80ff:fe65:8800%pppoe0 in pf.conf results in a
> rule referencing fe80::520f:80ff:fe65:8800

I'm not sure where the scope id gets stripped, but the above may simply
be a misleading cosmetic issue.

pfctl -sr uses inet_ntop() to convert the address into printable format.
It looks like this would never print the scope id (the %pppoe0 part of
the address).

The 'route get' command uses getnameinfo() instead, and getnameinfo()
has special handling for the scope_id which inet_ntop() lacks.

Someone would need to debug this to see if the scope id is present in
the binary representation of the rule's address, or if the scope id was
dropped somewhere on the way from pf.conf to the output of pfctl -sr.

> pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0

Rergardless, I would expect the above rule to work without an extra
entry in the routing table. Out of the box 'route get' displays the
correct route. Try: route get fe80::520f:80ff:fe65:8800%pppoe0
On my system this correctly identifies the outgoing interface as pppoe0.
And I have *not* done what you did below:

> hostname.pppoe0:
> !/sbin/route add -inet6 fe80::520f:80ff:fe65:8800 -ifp pppoe0 fe80::%pppoe0
> 
> This make pf able to route to the correct interface.

In my opinion having to add an extra route for this is a bug.
But I have no idea where :)



Re: OpenBSD 6.9 RAID 1C (encrypted raid1) softraid discipline can't boot

2021-04-28 Thread Stefan Sperling
On Wed, Apr 28, 2021 at 04:38:35PM +0800, Fung wrote:
> OpenBSD 6.9 RAID 1C (encrypted raid1) softraid discipline can't boot
> 
> OpenBSD 6.9 (GENERIC.MP) #473: Mon Apr 19 10:40:28 MDT 2021
> 
> one disk, shell create RAID CRYPTO, install system ok, boot ok
> two disk, shell create RAID 1,  install system ok, boot ok
> 
> two disk, shell create RAID 1C ok, install system ok, but boot failed in 
> starting 

There is no boot support for RAID 1C yet.



Re: pkg_add fails: 6.9 no such directory

2021-04-15 Thread Stefan Sperling
On Thu, Apr 15, 2021 at 09:25:31PM +0100, Björn Gohla wrote:
> 
> hi all,
> 
> i'm on 6.9 current. installing any package (example below) fails since there 
> is
> apparently no 6.9 release directory. what am i doin wrong?
> 
> thanks for any hints.

Try again like this: pkg_add -Dsnap gbc
This forces installation from snapshots/packages instead of 6.9/packages.

> titanic# pkg_add gbc
> https://cdn.openbsd.org/pub/OpenBSD/6.9/packages/amd64/: no such dir
> Can't find gbc



Re: IKEv1 support with IKEv2 on the same router

2021-04-14 Thread Stefan Sperling
On Wed, Apr 14, 2021 at 03:28:31PM +0300, Dev Op wrote:
> Hello all!
> 
> I have several partners working with different IKE versions. Is it possible
> to run iked and isakmpd on the same machine if I have two public
> IP addresses on it?
> 
> On iksampd (IKEv1) it's simple, for example:
> /etc/isakmpd/isakmpd.conf
> [General]
> Listen-on=X.X.X.X
> Retransmits=32
> Exchange-max-time=240
> DPD-check-interval=30
> Default-phase-1-lifetime=86400,60:86400
> Default-phase-2-lifetime=86400,60:86400
> 
> But how to bind iked (IKEv2) to another address Y.Y.Y.Y?

Running both on the same system isn't possible. As far as I understand
it's not just about the UDP listening ports. It isn't possible to share
the kernel's IPsec flow table cleanly between the two deamons.

You should be able to work around this limitation by running one of the
daemons in a virtual machine, e.g. in vmm(4), provided your hardware
supports this. Check: grep ^vmm0 /var/run/dmesg.boot
It is possible to bridge the VM's host-side network interface with the
physical network interface. This way, the VM could directly use one of
the two IP addresses, eliminating the need for NAT.

> $ uname -r
> 6.7

You should upgrade to 6.8 now. The 6.9 release is just around the corner.



  1   2   3   4   5   6   7   8   9   10   >