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.



Re: Intel wifi ipw showing up but not working

2021-03-28 Thread Stefan Sperling
On Sun, Mar 28, 2021 at 05:58:31PM +0200, Riccardo Mottola wrote:
> However, if you can read this message, it means that I am connected through
> the internal ipw card to WEP WiFi at the first attempt. Wonderful. Great
> work, Stefan,

Great, thank you for confirming! I have committed the fix.

Glad to know that old hardware and drivers like this are still useful.

Cheers,
Stefan



Re: Intel wifi ipw showing up but not working

2021-03-27 Thread Stefan Sperling
Hi Riccardo,

Any feedback regarding the proposed patch below?

Thanks,
Stefan

On Wed, Mar 17, 2021 at 04:09:32PM +0100, Stefan Sperling wrote:
> On Mon, Mar 15, 2021 at 02:11:39PM +0100, Riccardo Mottola wrote:
> > Stefan Sperling wrote:
> > > > That means there is another bug. I will try to find it.
> > > Could you show what 'netstat -W ipw0' looks like after an unsuccesful
> > > attempt of connecting to a WEP access point?
> > 
> > ipw0: flags=8843 mtu 1500
> > lladdr 00:0c:f1:1f:b2:a0
> > index 1 priority 4 llprio 3
> > groups: wlan
> > media: IEEE802.11 autoselect (DS11 mode 11b)
> > status: active
> > ieee80211: nwid westernesse chan 2 bssid 94:0c:6d:f7:a4:9c -61dBm
> > nwkey
> > 
> > 
> > then I run dhclient
> > 
> > ieee80211 on ipw0:
> > 0 input packets with bad version
> > 0 input packets too short
> > 0 input packets from wrong bssid
> > 0 input packet duplicates discarded
> > 0 input packets with wrong direction
> > 0 input multicast echo packets discarded
> > 0 input packets from unassociated station discarded
> > 0 input encrypted packets without wep/wpa config discarded
> > 0 input unencrypted packets with wep/wpa config discarded
> > 0 input wep/wpa packets processing failed
> > 0 input packet decapsulations failed
> > 2 input management packets discarded
> > 0 input control packets discarded
> > 0 input packets with truncated rate set
> > 0 input packets with missing elements
> > 0 input packets with elements too big
> > 0 input packets with elements too small
> > 0 input packets with invalid channel
> > 3 input packets with mismatched channel
> > 0 node allocations failed
> > 0 input packets with mismatched ssid
> > 0 input packets with unsupported auth algorithm
> > 0 input authentications failed
> > 0 input associations from wrong bssid
> > 0 input associations without authentication
> > 0 input associations with mismatched capabilities
> > 0 input associations without matching rates
> > 0 input associations with bad rsn ie
> > 0 input deauthentication packets
> > 0 input disassociation packets
> > 0 input packets with unknown subtype
> > 0 input packets failed for lack of mbufs
> > 0 input decryptions failed on crc
> > 0 input ahdemo management packets discarded
> > 0 input packets with bad auth request
> > 0 input eapol-key packets
> > 0 input eapol-key packets with bad mic
> > 0 input eapol-key packets replayed
> > 0 input packets with bad tkip mic
> > 0 input tkip mic failure notifications
> > 0 input packets on unauthenticated port
> > 0 output packets failed for lack of mbufs
> > 0 output packets failed for no nodes
> > 0 output packets of unknown management type
> > 0 output packets on unauthenticated port
> > 1 active scan started
> > 0 passive scans started
> > 0 nodes timed out
> > 0 failures with no memory for crypto ctx
> > 0 ccmp decryption errors
> > 0 ccmp replayed frames
> > 0 cmac icv errors
> > 0 cmac replayed frames
> > 0 tkip icv errors
> > 0 tkip replays
> > 0 pbac errors
> > 0 HT negotiation failures because peer does not support MCS 0-7
> > 0 HT negotiation failures because we do not support basic MCS set
> > 0 HT negotiation failures because peer uses bad crypto
> > 0 HT protection changes
> > 0 new input block ack agreements
> > 0 new output block ack agreements
> > 0 input frames below block ack window start
> > 0 input frames above block ack window end
> > 0 input block ack window slides
> > 0 input block ack window jumps
> > 0 duplicate input block ack frames
> > 0 expected input block ack frames never arrived
> > 0 input block ack window gaps timed out
> > 0 input block ack agreements timed out
> > 0 output block ack agreements timed out
> > 
> > 
> > The two "suspect" values im my humble opinion are:
> > 2 input management packets discarded
> > 3

Re: Is there any way I can help with ath10k?

2021-03-23 Thread Stefan Sperling
On Tue, Mar 23, 2021 at 03:13:38PM -0400, Brennan Vincent wrote:
> I do not know how to write wifi drivers, but I am willing to donate hardware
> or other resources if that would be helpful to someone. Please contact me if
> so.   

I have a WIP driver which loads firmware but it can neither scan nor
pass packets yet:
https://git.stsp.in-berlin.de/gitweb/?p=openbsd-src.git;a=shortlog;h=refs/heads/athx

There are more than enough cards in my stash which were supplied by the
community. I would not mind sharing this hardware with other developers.
I can collaborate if someone shows up who wants to work on this without
needing a lot of my time for mentoring. Otherwise, I will pick this back
up when I find time. At the moment there are other projects that are higher
on my list.

Cheers,
Stefan



Re: AX201 Surface Pro 7

2021-03-17 Thread Stefan Sperling
On Fri, Mar 05, 2021 at 07:15:11PM +0100, Stefan Sperling wrote:
> On Fri, Mar 05, 2021 at 04:25:53PM +0100, Fredrik Engberg wrote:
> > Hey, 
> > 
> > I had no luck with the "Qu-b0-hr-b0-48" firmware. But I had to change to 
> > "Qu-c0-hr-b0-48" and that seems to work.  Here it is the changes I had to 
> > do to get it working. I might have done something wrong here so please 
> > point it out to me. 
> > 
> 
> Great! Thank for you doing this :)
> 
> Your patch looks fine.

This has now been committed. Thanks again for your help!



Re: Intel wifi ipw showing up but not working

2021-03-17 Thread Stefan Sperling
On Mon, Mar 15, 2021 at 02:11:39PM +0100, Riccardo Mottola wrote:
> Stefan Sperling wrote:
> > > That means there is another bug. I will try to find it.
> > Could you show what 'netstat -W ipw0' looks like after an unsuccesful
> > attempt of connecting to a WEP access point?
> 
> ipw0: flags=8843 mtu 1500
> lladdr 00:0c:f1:1f:b2:a0
> index 1 priority 4 llprio 3
> groups: wlan
> media: IEEE802.11 autoselect (DS11 mode 11b)
> status: active
> ieee80211: nwid westernesse chan 2 bssid 94:0c:6d:f7:a4:9c -61dBm
> nwkey
> 
> 
> then I run dhclient
> 
> ieee80211 on ipw0:
> 0 input packets with bad version
> 0 input packets too short
> 0 input packets from wrong bssid
> 0 input packet duplicates discarded
> 0 input packets with wrong direction
> 0 input multicast echo packets discarded
> 0 input packets from unassociated station discarded
> 0 input encrypted packets without wep/wpa config discarded
> 0 input unencrypted packets with wep/wpa config discarded
> 0 input wep/wpa packets processing failed
> 0 input packet decapsulations failed
> 2 input management packets discarded
> 0 input control packets discarded
> 0 input packets with truncated rate set
> 0 input packets with missing elements
> 0 input packets with elements too big
> 0 input packets with elements too small
> 0 input packets with invalid channel
> 3 input packets with mismatched channel
> 0 node allocations failed
> 0 input packets with mismatched ssid
> 0 input packets with unsupported auth algorithm
> 0 input authentications failed
> 0 input associations from wrong bssid
> 0 input associations without authentication
> 0 input associations with mismatched capabilities
> 0 input associations without matching rates
> 0 input associations with bad rsn ie
> 0 input deauthentication packets
> 0 input disassociation packets
> 0 input packets with unknown subtype
> 0 input packets failed for lack of mbufs
> 0 input decryptions failed on crc
> 0 input ahdemo management packets discarded
> 0 input packets with bad auth request
> 0 input eapol-key packets
> 0 input eapol-key packets with bad mic
> 0 input eapol-key packets replayed
> 0 input packets with bad tkip mic
> 0 input tkip mic failure notifications
> 0 input packets on unauthenticated port
> 0 output packets failed for lack of mbufs
> 0 output packets failed for no nodes
> 0 output packets of unknown management type
> 0 output packets on unauthenticated port
> 1 active scan started
> 0 passive scans started
> 0 nodes timed out
> 0 failures with no memory for crypto ctx
> 0 ccmp decryption errors
> 0 ccmp replayed frames
> 0 cmac icv errors
> 0 cmac replayed frames
> 0 tkip icv errors
> 0 tkip replays
> 0 pbac errors
> 0 HT negotiation failures because peer does not support MCS 0-7
> 0 HT negotiation failures because we do not support basic MCS set
> 0 HT negotiation failures because peer uses bad crypto
> 0 HT protection changes
> 0 new input block ack agreements
> 0 new output block ack agreements
> 0 input frames below block ack window start
> 0 input frames above block ack window end
> 0 input block ack window slides
> 0 input block ack window jumps
> 0 duplicate input block ack frames
> 0 expected input block ack frames never arrived
> 0 input block ack window gaps timed out
> 0 input block ack agreements timed out
> 0 output block ack agreements timed out
> 
> 
> The two "suspect" values im my humble opinion are:
> 2 input management packets discarded
> 3 input packets with mismatched channel
> 
> Riccardo
> 

My best guess is that because ipw doesn't bother with calling into
the net80211 newstate function, the interface's link state is never
updated and packets cannot flow. With WPA, link state gets updated
as a side-effect of a successful WPA handshake.

Does this fix it?

diff 1ff4cf56fdff3473d72fc4b29d69428c688d47c6 /usr/src
blob - ab16cd51ba6a2efdf89ac588801a1ae2bc714ed5
file + sys/dev/pci/if_ipw.c
--- sys/dev/pci/if_ipw.c
+++ sys/dev/pci/if_ipw.c
@@ -679,7 +679,11 @@ int
 ipw_newstate(struct ieee80211com *ic, enum ieee80211_state nstate, int arg)
 {
  

Re: Intel wifi ipw showing up but not working

2021-03-12 Thread Stefan Sperling
On Fri, Mar 12, 2021 at 07:01:10PM +0100, Stefan Sperling wrote:
> On Fri, Mar 12, 2021 at 06:37:30PM +0100, Riccardo Mottola wrote:
> > Happy and bold, I tried WEP too... but it does not connect.
> > It says interface is up (key is correct) but "nothing", dhclient doesn't get
> > a link.
> > 
> > Fearing WEP is broken, I got my other laptop, a ThinkPad with 6.8, where I
> > have since long a small script. Launched it and works. Good. I copied over
> > the script... so I am sure I do the things the same way, but it does not
> > work.
> > What is very strange is that if I first connect to the WPA network, then
> > bring the interface down, kill dhclient, then run the WEP script, it works
> > and really connects to WEP and gets a lease.
> 
> That means there is another bug. I will try to find it.

Could you show what 'netstat -W ipw0' looks like after an unsuccesful
attempt of connecting to a WEP access point?



Re: Intel wifi ipw showing up but not working

2021-03-12 Thread Stefan Sperling
On Fri, Mar 12, 2021 at 06:37:30PM +0100, Riccardo Mottola wrote:
> > diff dfcb0a350e790649cafe6bd5f9f4cf2319ce75fd /usr/src
> > blob - 20a9b617e6d7ae0e179370512376ce8142c96986
> > file + sys/dev/pci/if_ipw.c
> > --- sys/dev/pci/if_ipw.c
> > +++ sys/dev/pci/if_ipw.c
> > @@ -1781,6 +1781,12 @@ ipw_auth_and_assoc(void *arg1)
> > if (error != 0)
> > goto fail;
> > +   /*
> > +* net80211 won't see the AP's AUTH response. Move to ASSOC state
> > +* in order to make net80211 accept the AP's assoc response.
> > +*/
> > +   ic->ic_newstate(ic, IEEE80211_S_ASSOC, -1);
> > +
> > return;
> >   fail:
> > printf("%s: association failed (error=%d)\n", sc->sc_dev.dv_xname,
> > 
> 
> I just tried your patch against 6.8 release sources, compiled... and yay!
> ipw0 connects to WPA WiFi just fine! Thanks, I hope it will make it in 6.9
> :)

Yes, thanks for testing! I have committed the patch.

> I did a test of sending 187MB over scp I getabout 500K/s, A little slow,
> even for 11b, I think. I'd expect more like 700, but anyway.

I don't think there is much that can be done about this.

I'd be glad that an 11b device is even usable. The presence of this device
will slow down any networks using the same channel so you might not make
a lot of friends while using this device on public wifi networks ;)
Some APs won't allow 11b clients for this reason.

> Happy and bold, I tried WEP too... but it does not connect.
> It says interface is up (key is correct) but "nothing", dhclient doesn't get
> a link.
> 
> Fearing WEP is broken, I got my other laptop, a ThinkPad with 6.8, where I
> have since long a small script. Launched it and works. Good. I copied over
> the script... so I am sure I do the things the same way, but it does not
> work.
> What is very strange is that if I first connect to the WPA network, then
> bring the interface down, kill dhclient, then run the WEP script, it works
> and really connects to WEP and gets a lease.

That means there is another bug. I will try to find it.

Cheers,
Stefan



Re: Intel wifi ipw showing up but not working

2021-03-11 Thread Stefan Sperling
On Thu, Mar 11, 2021 at 08:05:53PM +0100, Riccardo Mottola wrote:
> Hi Stefan,
> 
> sorry for the delayed response, but dayjob took over and for that I
> unfortunately cannot use an old OpenBSD laptop with no wireless :) Also I
> had to use another system to conveniently do the tests you asked me.

No worries! I am not in a rush :)

> tecra$ netstat -W ipw0
> ieee80211 on ipw0:

> 10 input management packets discarded

This one looks bad. I think it means the net80211 stack ends up ignoring
the AP's assoc response frame. I believe your situation is that the
firmware is in associated state, the driver itself sets media status to
'active' in response to the firmware signalling successful association,
but the net80211 stack has not participated in the association sequence so
no WPA handshake can happen. The incoming data packets indicate that the
AP is trying to initiate the WPA handshake but net80211 doesn't expect
such packets and doesn't respond.

The way the association sequence works in this driver is pretty weird...

Can you try this patch? Does it change anything?

diff dfcb0a350e790649cafe6bd5f9f4cf2319ce75fd /usr/src
blob - 20a9b617e6d7ae0e179370512376ce8142c96986
file + sys/dev/pci/if_ipw.c
--- sys/dev/pci/if_ipw.c
+++ sys/dev/pci/if_ipw.c
@@ -1781,6 +1781,12 @@ ipw_auth_and_assoc(void *arg1)
if (error != 0)
goto fail;
 
+   /*
+* net80211 won't see the AP's AUTH response. Move to ASSOC state
+* in order to make net80211 accept the AP's assoc response.
+*/
+   ic->ic_newstate(ic, IEEE80211_S_ASSOC, -1);
+
return;
 fail:
printf("%s: association failed (error=%d)\n", sc->sc_dev.dv_xname,



Re: AX201 Surface Pro 7

2021-03-05 Thread Stefan Sperling
On Fri, Mar 05, 2021 at 04:25:53PM +0100, Fredrik Engberg wrote:
> Hey, 
> 
> I had no luck with the "Qu-b0-hr-b0-48" firmware. But I had to change to 
> "Qu-c0-hr-b0-48" and that seems to work.  Here it is the changes I had to do 
> to get it working. I might have done something wrong here so please point it 
> out to me. 
> 

Great! Thank for you doing this :)

Your patch looks fine.

Now we are only missing a patch for the sysutils/firmware/iwx port
such that this new firmware file can be installed with fw_update.
Ideally, the firmware port should be updated before support for
this new device is added to the driver.

And fw_update will need an updated and signed firmware package on
the mirrors. The person who currently takes care of uploading the
official firmware packages is sthen@ so please get in touch with
him if you want to finish the job.

Regards,
Stefan



Re: OpenBSD 6.8 - softraid issue: "uvm_fault(0xffffffff821f5490, 0x40, 0, 1) -> e"

2021-03-02 Thread Stefan Sperling
On Tue, Mar 02, 2021 at 09:39:15AM +, Stuart Henderson wrote:
> putting sr_validate_io+0x44 at the xs->datalen dereference,
> 
> 4580 if (sd->sd_vol_status == BIOC_SVOFFLINE) {
> 4581 DNPRINTF(SR_D_DIS, "%s: %s device offline\n",
> 4582 DEVNAME(sd->sd_sc), func);
> 4583 goto bad;
> 4584 }
> 4585
> 4586 if (xs->datalen == 0) {
> 4587 printf("%s: %s: illegal block count for %s\n",
> 4588 DEVNAME(sd->sd_sc), func, sd->sd_meta->ssd_devname)  
>;
> 4589 goto bad;
> 4590 }
> 
> ...so null/invalid xs?

Yes, I've looked at this function already and I think a bad deref of xs
is the only reasonable explanation. But we don't know how that happens.



Re: OpenBSD 6.8 - softraid issue: "uvm_fault(0xffffffff821f5490, 0x40, 0, 1) -> e"

2021-02-28 Thread Stefan Sperling
On Sun, Feb 28, 2021 at 03:05:49AM +0100, Mark Schneider wrote:
> Hi again,
> 
> I have repeated softraid tests using six pcs of 1TB Samsung HDD 3G SATA
> drives as RAID5 and I do not face the crash issue of the OS when using SSDs
> in the RAID5.
> Details of the RAID5 setting are in the attached file.
> 
> It looks like using SSD drives as RAID5 leads for some reason to the OpenBSD
> 6.8 crash. Samsung 512MB PRO 860 SSDs have 6G SATA interface (what is
> different compared to tested HDDs)
> 
> NB: Using those SSDs as RAID6 on debian Linux (buster - mdadm / cryptoLUKS)
> does not face any issues
>   There are also no issues using those SSDs as RAID on FreeBSD
> (TrueNAS).

I've seen some Samsung Pro SSDs cause I/O errors on ahci(4) due to unhandled
NCQ error conditions. Not sure if this relates to your problem; I assume that
these errors were specific to my machine, which is over 10 years old. Its AHCI
controller has likely not been designed with modern SSDs in mind. I switched
to different SSDs and the problem disappeared. This was on RAID1 where the
kernel didn't crash. Instead, the volume ended up in degraded state.

Maybe some I/O error is happening in your case as well?
Perhaps the raid5 code doesn't handle i/o errors gracefully?

In any case, your bug report is missing important information:

> > # Error messages
> > 
> > uvm_fault(0x821f5490, 0x40, 0, 1) -> e
> > kernel: page fault trap, code=0
> > Stopped at  sr_validate_io+0x44:    cmpl $0,0x40(%r9)
> > ddb{2}>

This tells us where it crashed but not how the code flow ended up here.
Please show the stack trace printed by the 'trace' command, and the output
of the 'ps' command (both commands at the ddb> prompt).



Re: Bufferbloat, FQ-CoDel, and performance

2021-02-24 Thread Stefan Sperling
On Tue, Feb 23, 2021 at 09:04:13PM -, Stuart Henderson wrote:
> On 2021-02-23, Stuart Henderson  wrote:
> > On 2021-02-23, Steven Shockley  wrote:
> >> I have OpenBSD 6.8 running on a Dell R210-II acting as a 
> >> firewall/router.  To combat bufferbloat I tried implementing FQ-CoDel 
> >> queueing.  The WAN bandwidth is advertised as 940 Mbit/sec down and 840 
> >> Mbit/sec up.
> >
> > Flow queues are broken in 6.8 on interfaces with hw checksum offloading.
> > Fix is in -current or sys/net/pf.c r1.1096
> 
> Oops, on interfaces *without* hw checksum offloading, like this:
> 
> $ ifconfig em0 hwfeatures
> em0: flags=8843 mtu 1500
>   hwfeatures=10 hardmtu 9216
> ..
> 

Thank you Stuart! This seems to have fixed the issue for me (on a 6.8
system which now also carries the r1.1096 pf.c patch).



Re: Bufferbloat, FQ-CoDel, and performance

2021-02-23 Thread Stefan Sperling
On Mon, Feb 22, 2021 at 08:51:32PM -0500, Steven Shockley wrote:
> I have OpenBSD 6.8 running on a Dell R210-II acting as a firewall/router.
> To combat bufferbloat I tried implementing FQ-CoDel queueing.  The WAN
> bandwidth is advertised as 940 Mbit/sec down and 840 Mbit/sec up.
> 
> I've tried adding one or the other of these lines to my pf.conf:
> 
> queue outq on $ext_if flows 1024 bandwidth 1024M max 1024M qlimit 1024
> default
> or
> queue outq on $ext_if flows 1024 qlimit 1024 default
> 
> In both cases, upload speeds drop from ~800 Mbit/sec to < 100 Mbit/sec.
> Changing the 1024M to other values makes little or no difference.  To be
> fair, bufferbloat does improve, but that's quite a hit.  I'm measuring using
> the dslreports.com speed test via wired ethernet through a Cisco 3750x.
> 
> One possible complexity is that the internal interface is tagged VLANs, but
> if it were an MTU issue I'd expect it to affect performance across the
> board.
> 
> Any suggestions?  I'm happy to post dmesg/pf.conf/diagrams if they'd help.
> Thanks.

I've noticed a similar effect on a slower link (VDSL with 50 down/ 10 up).
In this case the VDSL modem presents an Ethernet switch, so there is no
pppoe or vlan involved in the box that runs pf.

As soon as I enable this example given in pf.conf(5):

 queue outq on em0 bandwidth 9M max 9M flows 1024 qlimit 1024 \
   default

I see only about 2 or 3 Mbit/s max upload during tcpbench.
Which is indeed quite a hit compared to 10M.

Without the queue tcpbench goes up to 9 Mbit/s. It varies a lot between
5 and 9, which I thought might be a reason for my issue with queueing
enabled.

Currently, I am simply running this setup without any queueing.



Re: PC Engines APU2 boot problem

2021-02-17 Thread Stefan Sperling
On Wed, Feb 17, 2021 at 12:08:52PM +0100, Raimo Niskanen wrote:
> Hello misc!
> 
> I have problem booting an APU2 from SD card and USB stick.
> It boots fine from the mSATA disk where I have the OpenBSD installation
> that I have upgraded several times using sysupgrade(8).
> 
> I have tried to write install67.fs and install68.img to an SD card and to
> an USB stick from a Linux machine using e.g
> dd if=install67.fs of=/dev/sdc bs=1M
> 
> On the APU:s serial console, I press [F10] to get a boot prompt, and then
> select the SD card or the USB stick.  The kernel is loaded and the last
> printout is "Entry point: 0x..." something.  The next line
> [ELF ... whatnot] does not come.  After a while the APU resets and boots
> again, or sometimes hangs.

Before loading a kernel the serial console needs to be enabled with:

  stty com0 115200
  set tty com0

On an installed system /etc/boot.conf is usually set up to do this
automatically but manual setup is still required when booting from
other media.



Re: Intel wifi ipw showing up but not working

2021-02-17 Thread Stefan Sperling
On Tue, Feb 16, 2021 at 11:51:12PM +0100, Riccardo Mottola wrote:
> Hi Stefan,
> 
> 
> Stefan Sperling wrote:
> > Sounds like a wrong key, or the wrong type of crypto.
> > Are you the AP is using WEP? Perhaps you need 'wpakey' instead of 'nwkey'?
> 
> If the key is wrong or the crypto is wrong, would the interface still be
> active and connected?

With WEP, if the key is wrong, the interface will appear connected
but it will be unable to communicate. There is no setup phase in WEP.
You either encrypt and decrypt packets with the correct key, or you
don't.

With WPA, the link should no reach 'active' state unless you are using
the correct passphrase. This is because the AP and client will try to
negotiate a per-client session key, and if this key cannot be obtained,
the link will stay down. The interface flags will show UP, however.

> I am sure the AP is using WEP: I connect to that access point with many
> computer since years.
> Also, I tried connectiong to another access point which has WPA, same
> failure.

OK, thanks for confirming.

> The script proves that the network settings if applied are correct and do
> work and that I do not "mistype"!

Yes, since the WPA link is 'active' the key should be correct.

The next step is getting a DHCP lease.
If DHCP does not manage to obtain a lease, something is wrong.
Perhaps this driver was broken somehow for multicast encryption or decryption.

What does this command print before, and after, an attempt to connect?

  netstat -W ipw0

What does this command display while you are trying to connect?

  tcpdump -n -i ipw0 -y IEEE802_11_RADIO -D in -s 4096



Re: Intel wifi ipw showing up but not working

2021-02-15 Thread Stefan Sperling
On Sun, Feb 14, 2021 at 02:23:08PM +0100, Riccardo Mottola wrote:
> Hi Stuart and others,,
> 
> 
> Stuart Henderson wrote:
> > 
> > > I installed the firmware with fw_update. I try to bring the interface
> > > up, I can set the nwid, but it never connects.
> > What do you type to bring the interface up?
> > If you are using /etc/hostname.ipw0 and "sh /etc/netstart ipw0", what
> > are the contents of the file?
> 
> I am typing "ifconfig ipw0 up" as root (or sudo) and then directly starting
> the interface with dhclient.
> 
> > > I set the WEP password and it does not get saved if I check back with
> > > ifconfig.
> > WEP password definitely won't get displayed back if you check as non-root.
> > I don't recall if it is displayed for root or not.
> 
> It is not - I was confused with another BSD which does, as root, display
> back the used key.
> 
> > What does "ifconfig ipw0" say?
> > 
> > Is there an "RF kill" (wifi on/off) switch on the laptop, if so did you
> > try toggling it?
> 
> Actually, that was the solution. The laptop has both a "soft" button with
> Fn-F8 and a HW toggle, I forgot about the latter. I am not accustomed to
> having "both". (Add to that that it is invisible gray and acts the opposite,
> sliding right "kills" and not "activates" but the icon hints to right with
> an antenna not a off-antenna)
> 
> I am used that on other laptops, the toggle issues a send connect/disconnect
> of the device, here it seems that the device is up but with no antenna.
> 
> > If I try to scan, nothing is shown, I get no errors on the console/dmesg.
> > 
> > I tried enabling debug and I see:
> > 
> > ifconfig debug ipw0 list
> > ifconfig: SIOCDIFADDR: Device not configured
> > Syntax for that is "ifconfig ipw0 debug", if you get any messages they'll
> > appear in dmesg and/or /var/log/messages
> 
> 
> Thanks for the pinpoint. Now with the correct settings I finally see the LED
> on. The interface comes up and finally says "active" when it attaches to the
> correct SSID. A scan shows all network, so I believe the radio is fine.
> 
> dhclient however fails to get an address. It waits a few instants and then
> prints "no link".
> 
> That is very strange, if with ifconfig I got the interface to active and
> thus connected. Am I overseeing again something obvious?
> 
> Riccardi
> 
> 

Sounds like a wrong key, or the wrong type of crypto.
Are you the AP is using WEP? Perhaps you need 'wpakey' instead of 'nwkey'?

If you want more help, please show commands you are typing and their output.
It is much easier to provide help when we can see what you are seeing,
instead of trying to guess what happened based on your verbal description.



Re: Bootloader on USB stick fails with "root device not found"

2021-02-11 Thread Stefan Sperling
On Thu, Feb 11, 2021 at 06:56:40PM +, tetrahe...@danwin1210.me wrote:
> On Sun, Jan 31, 2021 at 12:06:37PM +0100, Stefan Sperling wrote:
> > On Sun, Jan 31, 2021 at 11:47:04AM +0100, Stefan Sperling wrote:
> > > In general, crypto softraid volumes don't auto-assemble.
> > 
> > I forgot that softraid volumes that use a key disk instead of a
> > passphrase will auto-assemble. Have you already tried that?
> > A disklabel slice on the USB key could act as a key disk for
> > the encrypted volume on the internal disk.
> 
> I am looking at the manpage for bioctl(8) and I don't see any provision for
> either changing the passphrase of an existing encrypted disk,

Changing the passphrase can be done. From bioctl(8):

 -P  Change the passphrase on the selected crypto volume.

> or replacing the passphrase with a keydisk.

AFAIK that cannot be done. I agree it would be nice to have.

> Is there any way to change my existing install over to using a keydisk,
> instead of a passphrase? Or do I need to wipe everything and re-install?

Yes, wipe and reinstall is the way to go. This could be used as an
opportunity to go through the backup and restore steps required to
get the system working again after losing the key disk :)

To easily restore your installed packages after a re-install check
out the -z options of pkg_info and pkg_add. Combined with backups of
important files this makes the process not too painful.



Re: Bootloader on USB stick fails with "root device not found"

2021-02-10 Thread Stefan Sperling
On Wed, Feb 10, 2021 at 01:00:33PM +, Frank Beuth wrote:
> On Tue, Feb 02, 2021 at 10:50:39PM +0100, Stefan Sperling wrote:
> > The idea of protecting key disks with a passphrase (two-factor auth) has
> > been raised before. It has not been implemented yet, simply because nobody
> > has done the work. A search of the mailing list archives should yield
> > some prior discussion.
> 
> How about backup keys, so I can have a backup passphrase stored somewhere
> safely that works even if I lose my keydisk?

Well, even if two-factor auth were already available, if you lose
the key disk then you should also lose access to the encrypted data.
Otherwise it's not two-factor auth. A scheme where either a passphrase
or a key disk could be used to unlock the volume would be redundant and
even dangerously confusing for users who expect actual two-factor auth.

The current way to back up a keydisk is by saving an image with dd and
storing this somewhere securely. This image can be very small since only
the key disk's RAID disklabel slice needs to be copied, not the entire
physical key disk. See the FAQ entry "Using a Keydisk" here:
https://www.openbsd.org/faq/faq14.html#softraid



Re: AX201 Surface Pro 7

2021-02-05 Thread Stefan Sperling
On Fri, Feb 05, 2021 at 11:38:24AM +0100, Fredrik Engberg wrote:
> Hey 
> 
> I got myself a Surface Pro 7 and thought it had a supported AX201 wifi chip 
> in it but after some looking around in the source I couldn’t find the device 
> ID in there so I tried myself to add it to pcidevs and pcidevs.h. 
> I also added the pci_products to if_iwx.c and pcidevs_data.h. I got it to 
> show up in dmesg. But I get “iwx0: unsupported AX201 adapter". I think Im in 
> a bit of deep water here and my knowledge is to low for it. Im wondering if 
> someone else has gotten this AX1650 card to work? 
> 
> Here is pcidump from the machine: 
> 
>  0:20:3: Intel unknown
>   0x: Vendor ID: 8086, Product ID: 34f0
>   0x0004: Command: 0006, Status: 0010
>   0x0008: Class: 02 Network, Subclass: 80 Miscellaneous,
>   Interface: 00, Revision: 30
>   0x000c: BIST: 00, Header Type: 80, Latency Timer: 00,
>   Cache Line Size: 00
>   0x0010: BAR mem 64bit addr: 0x006002134000/0x4000
>   0x0018: BAR empty ()
>   0x001c: BAR empty ()
>   0x0020: BAR empty ()
>   0x0024: BAR empty ()
>   0x0028: Cardbus CIS: 
>   0x002c: Subsystem Vendor ID: 8086 Product ID: 0074
>   0x0030: Expansion ROM Base Address: 
>   0x0038: 
>   0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00
>   0x00c8: Capability 0x01: Power Management
>   State: D0
>   0x00d0: Capability 0x05: Message Signalled Interrupts (MSI)
>   Enabled: no
>   0x0040: Capability 0x10: PCI Express
>   Max Payload Size: 128 / 128 bytes
>   Max Read Request Size: 128 bytes
>   0x0100: Enhanced Capability 0x18: Latency Tolerance Reporting
>   0x0164: Enhanced Capability 0x0b: Vendor-Specific
>   0x0080: Capability 0x11: Extended Message Signalled Interrupts (MSI-X)
>   Enabled: yes; table size 16 (BAR 0:8192)
> 
> 
> //Fredrik Engberg 
> 
> 

This device needs firmware "Qu-b0-hr-b0-48"
You can find the firmware image here:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git 

The iwx driver will need corresponding changes to detect your device
and load this specific firmware image. Then it will hopefully work.



Re: Bootloader on USB stick fails with "root device not found"

2021-02-02 Thread Stefan Sperling
On Tue, Feb 02, 2021 at 07:04:38AM +, tetrahe...@danwin1210.me wrote:
> Looking thru the manpages, I don't see any provision for adding AND / OR
> logic to keys (e.g require both passphrase AND keydisk to boot, require
> passphrase OR keydisk, etc) the way Linux cryptsetup provides, at least,
> OR-logic across multiple keyslots.
> 
> (Having multiple keyslots on an encrypted volume has saved me a few times!)
>
> Is there anything like this in OpenBSD?

It is possible to add multiple key disk slices (type RAID) to the same
disklabel.  This way, a single USB stick could unlock multiple volumes.

The idea of protecting key disks with a passphrase (two-factor auth) has
been raised before. It has not been implemented yet, simply because nobody
has done the work. A search of the mailing list archives should yield
some prior discussion.
I would also make use of this feature if it was available. I'd be happy to
review and test relevant patches.



Re: "No O/S" after drive replacement with / on raid1

2021-02-01 Thread Stefan Sperling
On Sun, Jan 31, 2021 at 09:47:22PM +0300, Serge wrote:
> Hello.
> 
> I use 2 disks in mirror with root partition on softraid.
> Say they are sd0a and sd1a and SR is sd2.
> For example sd0 fails. I shutdown system, replace failed drive, 
> boot from good one, copy layout, rebuild array, all disks online 
> and system is up and running.
> Then sd1 fails. I shutdown system, replace sd1, power on and...
> 
> Using drive 0, partition 3.
> No O/S
> _
> 
> 
> Reading manuals, faqs and mailing lists led me to the following:
> I reproduce the issue and after replacement first failed drive run
> # installboot -v sd2
> 
> After that I can boot successfully from both drives.
> 
> Unfortunately I can not find this solution (is it a solution?) 

Yes, this is the right solution.

Installboot writes the bootloader to all chunks. If a chunk is replaced
with a fresh disk this disk won't carry a boot loader unless installboot
is run again.



Re: Bootloader on USB stick fails with "root device not found"

2021-01-31 Thread Stefan Sperling
On Sun, Jan 31, 2021 at 11:47:04AM +0100, Stefan Sperling wrote:
> In general, crypto softraid volumes don't auto-assemble.

I forgot that softraid volumes that use a key disk instead of a
passphrase will auto-assemble. Have you already tried that?
A disklabel slice on the USB key could act as a key disk for
the encrypted volume on the internal disk.



Re: Bootloader on USB stick fails with "root device not found"

2021-01-31 Thread Stefan Sperling
On Sat, Jan 30, 2021 at 09:57:35PM +, tetrahe...@danwin1210.me wrote:
> On Fri, Jan 29, 2021 at 12:46:50PM +, tetrahe...@danwin1210.me wrote:
> > - when booting from the bootloader on the internal HD, and after
> > decrypting the encrypted volume, the system is able to find the disk
> > e8 without trouble, but
> > 
> > - when booting from the bootloader on the USB stick, and after
> > decrypting the same encrypted volume (with the same password, etc),
> > the system is NOT able to find the disk e8.
> > 
> > What the heck is going on? Why can't the system find softraid volume
> > that it just decrypted?
> 
> Still haven't been able to find a solution to this. The boot, softraid,
> installboot manpages (as far as I can tell) offer no answers.
> 
> Does anyone here understand how the kernel looks for available volumes
> during the boot sequence?
> 
> Why would the kernel, when booted from a bootloader on one physical disk, be
> able to find a root device -- but, when booted from a bootloader on a
> different physical disk, not be able to do so? (even when the bootloaders in
> both cases decrypted the correct disk)

In general, crypto softraid volumes don't auto-assemble.
FDE boot only works because the kernel and boot-loader cooperate to make
sure that the softraid volume the kernel was booted from will be assembled.
Other volumes won't be assembled. You can expect to mount a softraid root
disk on the USB stick when booting off USB, but not from any other disk.

Your setup is missing a way to effectively run the right 'bioctl -C ...'
command to set up the missing volume. bioctl sits in the root filesystem
so there is a chicken-and-egg problem with running bioctl. You'd have to
change the bootloader and kernel to do the equivalent for you.

If you're not comfortable to fix the kernel and/or bootloader yourself for
this use case, just go with the working setup everyone else is using.



Re: 4G mini PCI-e modem support?

2021-01-08 Thread Stefan Sperling
On Fri, Jan 08, 2021 at 05:13:52PM +0100, Patrick Wildt wrote:
> Am Fri, Jan 08, 2021 at 02:29:02PM + schrieb Peter Kay:
> > There appear to be no 4G modem support at the moment, specifically a
> > mini PCI-e one so I can stick it in a PC engines apu4d4 and have a
> > backup connection.
> > 
> > Presuming a driver would need to be written, but just checking if I've
> > missed anything?
> 
> There's umb(4).  It supports USB's MBIM standard.  There are some MBIM
> compatible chips around, one for instance is this one:
> 
> https://www.varia-store.com/de/produkt/87272-simcom-sim7600e-h-mpcie-eu-lte-cat-4-modul.html
> 
> You'll probably need to switch it into MBIM mode once via a specific
> AT-command over the serial, but otherwise it should do.
> 
> I'm sure there are plenty of other MBIM-compatible devices, this is just
> the one from the top of my head.

I have umb(4) working on an APU1 board. It's a Sierra Wireless EM7345, the one
shipped with x250 Thinkpads. Installation in an APU requires a compatible M.2
to miniPCIe adapter. Make sure to get an adapter with the correct M.2 keying.
If the vendor advertises GSM/UMTS/LTE modem support the adapter should work.
If they don't, better ask before buying.

This combo works fine in the middle miniPCIe slot of the APU. You'll need a
full size SIM card for the SIM card slot. Again, an adapter will help to fit
a micro or nano SIM.

You will also want LTE antennas and compatible pigtails. Using wifi antennas
will result in about 50% packet loss.



Re: Git Daemon rc Script Not Stopping

2021-01-05 Thread Stefan Sperling
On Tue, Jan 05, 2021 at 03:19:29PM -0500, ben wrote:
> >The original version of this script installed by the port contains
> >rc_reload=NO and also uses a very different pexp.
> 
> I checked out the original rc script, and it works. Why didn't my pexp var 
> work
> for the script? The term should match the process, and yet the daemon was 
> still
> running?
> 
> 

Because the process is called "git-daemon", not "git", and the rc.d
framework passes the -x option to pgrep.



Re: Git Daemon rc Script Not Stopping

2021-01-05 Thread Stefan Sperling
On Tue, Jan 05, 2021 at 02:41:51PM -0500, ben wrote:
> Hello, Misc;
> 
> I've been playing around with rc.d scripts and I've stumbled upon an issue in
> my git daemon script:
> 
> #!/bin/ksh
> #
> # $OpenBSD: gitdaemon.rc,v 1.4 2019/07/16 09:56:55 stsp Exp $
> 
> daemon="/usr/local/libexec/git/git-daemon --detach"
> daemon_flags=" --detach --export-all --reuseaddr --base-path=/home/git 
> /home/git"
> daemon_user="git"
> 
> . /etc/rc.d/rc.subr
> 
> pexp=git
> 
> rc_cmd $1

The original version of this script installed by the port contains
rc_reload=NO and also uses a very different pexp.
Why did you see a need to modify this script? Could you not simply set
these options in /etc/rc.conf.local and use the unmodified script?

gitdaemon_flags=--export-all --reuseaddr --base-path=/home/git /home/git
gitdaemon_user=git



Re: Getting wifi bitrate

2021-01-02 Thread Stefan Sperling
On Fri, Jan 01, 2021 at 02:13:43PM +, Björn Gohla wrote:
> 
> [...]
> >> I just want to show the network activity in my desktop status line.
> >
> > Understood, fair enough.
> > The chosen Tx rate is not a very reliable indicator of actual throughput
> > but it can serve as a wifi link quality indicator to some extent.
> 
> >From ifconfig.c I gather that
> 
> (nr->nr_rates[nr->nr_nrates - 1] & IEEE80211_RATE_VAL) / 2
> 
> is the current nominal rate in Mb/s, is that correct?
> 
> Curiously, what I observe with the RTL8192EU is that after associating,
> that value starts at 1 and as transmissions are made, moves to 54 in
> increasing steps, and then stays there. I guess that corroborates your
> point about incorrect information being returned by the device.

That seems fine.
The driver is adjusting the Tx rate up from 1 mbit to 54 mbit and then
stays there since the Tx retry count is low enough even at 54 mbit.

On devices which don't report anything you'd *always* see 54.



Re: Getting wifi bitrate

2020-12-31 Thread Stefan Sperling
On Thu, Dec 31, 2020 at 04:13:56PM +, Björn Gohla wrote:
> 
> Stefan Sperling writes:
> 
> > On Thu, Dec 31, 2020 at 02:28:35PM +, Björn Gohla wrote:
> >> Hi all,
> [...]
> >> So how do I get the it? Am I looking in the wrong place, or does the
> >> driver just not expose this information?
> >
> > Rate/MCS + channel width + some other parameters map to a Tx bitrate:
> > https://en.wikipedia.org/wiki/IEEE_802.11n-2009#Data_rates
> >
> > This Tx bitrate will vary on a per-frame basis, though. And actual user data
> > throughput is always below this, due to protocol overhead, re-transmissions,
> > interference, other traffic on the same channel, and so on.
> 
> Right, so by using the values in that table one could extract a nominal
> Tx rate, but not the actual one (much less the Rx); correct?

Rx rates can only be observed with tcpdump -v -y IEEE802_11_RADIO -i urtwn0

> > In 11g mode the per-frame Tx rate is displayed by ifconfig in Mbit/s.
> > However, some realtek devices (like the 8192CU) perform Tx rate-adjustment
> > in firmware and do not even expose the chosen Tx data rate to the driver.
> > In that case ifconfig always displays 54M which is usually incorrect.
> 
> ifconfig says this:
> urtwn0: flags=808843 mtu 
> 1500
>  lladdr 54:2a:a2:4c:0e:b5
>  index 8 priority 4 llprio 3
>  groups: wlan egress
>  media: IEEE802.11 autoselect (OFDM54 mode 11g)
>  status: active
>  ieee80211: join "451UnavailableForLegalReasons " chan 11 bssid 
> b0:bb:e5:13:7b:d4 -72dBm wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp 
> wpagroupcipher tkip
>  inet 192.168.1.182 netmask 0xff00 broadcast 192.168.1.255
> 
> I suppose the "media" line is what you're referring to here, right?

Yes.
 
> dmesg says:
> urtwn0 at uhub0 port 2 configuration 1 interface 0 "Realtek Wireless N Nano 
> USB Adapter" rev 2.10/2.00 addr 2
> urtwn0: MAC/BB RTL8192EU, RF 6052 2T2R, address 54:2a:a2:4c:0e:b5
> 
> the device looks similar to the one you mentioned, so maybe that's
> what's going on here.

On 8192EU devices the driver will adjust the Tx rate. If you send a lot
of traffic the displayed Tx rate should change while you change the
physical distance to your AP, for example.
 
> > What problem are you trying to solve?
> 
> I just want to show the network activity in my desktop status line.

Understood, fair enough.
The chosen Tx rate is not a very reliable indicator of actual throughput
but it can serve as a wifi link quality indicator to some extent.



Re: Getting wifi bitrate

2020-12-31 Thread Stefan Sperling
On Thu, Dec 31, 2020 at 02:28:35PM +, Björn Gohla wrote:
> Hi all,
> 
> I have a small question: I want to get the current rate of actually
> transmitted (and received) bits for my wifi adaptor. I thought this
> fragment from ifconfig does what I want
> (https://github.com/openbsd/src/blob/3a44e88910781e836bd51a8b6b068379abc67a1b/sbin/ifconfig/ifconfig.c#L2783):
> 
> if ((nr->nr_flags & (IEEE80211_NODEREQ_AP)) == 0) {
>   if (nr->nr_flags & IEEE80211_NODEREQ_VHT) {
> printf("VHT-MCS%d/%dSS", nr->nr_txmcs, nr->nr_vht_ss);
>   } else if (nr->nr_flags & IEEE80211_NODEREQ_HT) {
> printf("HT-MCS%d ", nr->nr_txmcs);
>   } else if (nr->nr_nrates) {
> printf("%uM ",
>  (nr->nr_rates[nr->nr_txrate] & IEEE80211_RATE_VAL)
>  / 2);
>   }
> } else if (nr->nr_max_rxrate) {
>   printf("%uM HT ", nr->nr_max_rxrate);
>  } else if (nr->nr_rxmcs[0] != 0) {
>   for (i = IEEE80211_HT_NUM_MCS - 1;
>i >= 0; i--) {
> if (nr->nr_rxmcs[i / 8] & (1 << (i / 10)))
>   break;
>   }
>   printf("HT-MCS%d ", i);
>  } else if (nr->nr_nrates) {
>   printf("%uM ",
>(nr->nr_rates[nr->nr_nrates - 1] &
> IEEE80211_RATE_VAL) / 2);
>  }
> 
> But when I paste that into my application code and run it I get
> "HT-MCS23". My best understanding is that this refers to some definition
> of modulation coding schemes, i.e., not the bitrate I'm looking for.
> 
> So how do I get the it? Am I looking in the wrong place, or does the
> driver just not expose this information?

Rate/MCS + channel width + some other parameters map to a Tx bitrate:
https://en.wikipedia.org/wiki/IEEE_802.11n-2009#Data_rates

This Tx bitrate will vary on a per-frame basis, though. And actual user data
throughput is always below this, due to protocol overhead, re-transmissions,
interference, other traffic on the same channel, and so on.

> The interface is a "Realtek Wireless N Nano USB Adapter" in case that is
> relevant.

OpenBSD realtek wifi drivers only support 11g mode at present.
So on such hardware the kernel and ifconfig never report "MCS23".
MCS are only reported for 11n/ac modes.

In 11g mode the per-frame Tx rate is displayed by ifconfig in Mbit/s.
However, some realtek devices (like the 8192CU) perform Tx rate-adjustment
in firmware and do not even expose the chosen Tx data rate to the driver.
In that case ifconfig always displays 54M which is usually incorrect.

What problem are you trying to solve?



Re: development best practices

2020-11-28 Thread Stefan Sperling
On Sat, Nov 28, 2020 at 12:27:47PM +, björn gohla wrote:
> hi all,
> 
> i'm fairly new to openbsd. and i've run into the following problem,
> where i want to hack a project (most recently trying to fix a possible
> issue with i3status), but building the from the git source
> tree fails.
> 
> now, in the specific case, i'm trying to build a version that,
> also exists in ports, so we know it can be built on openbsd; and i
> presume the various patches included with the port are what makes it
> work.
> 
> i could of course try to apply those patches and fix my issue. but then
> when i submit a PR upstream i'd have to remove them again. that seems
> cumbersome, expecially if done repeatedly.
> 
> so what is the best practice in this situation? should i just upstream
> the ports patches?

You could edit the source files which are extracted to /usr/ports/pobj/
when the port is built. If you modify a file the port has not patched
yet, create a copy of this file with a .orig filename extension first.

'make update-patches' in the port's directory will diff files against
their .orig versions and update patches the port's patches directory.

You can then extract your fix and apply it to an upstream development tree.
If additional patches are required to get the software to compile, you
might as well attempt to upstream those changes, too, while at it.



Re: A new race condition in OpenVPN and Unbound services

2020-11-21 Thread Stefan Sperling
On Fri, Nov 20, 2020 at 11:21:00PM -0500, Predrag Punosevac wrote:
> 
> Hi Misc,
> 
> Has anybody else noticed a new race condition causing Unbound to fail
> due to the fact that OpenVPN interface is not available. 
> 
> Since a few releases ago I have this in my rc.conf.local to start
> openvpn server and unbound
> 
> openvpn_flags=--config /etc/openvpn/server.conf
> pkg_scripts=sshguard collectd smartd openvpn
> sensorsd_flags=
> snmpd_flags=
> syslogd_flags="-h"
> unbound_flags=
> 
> Previously I was starting OpenVPN server via 
> /etc/hostname.tun0 
> 
> file
> 
> up link0
> !/usr/local/sbin/openvpn --daemon --config /etc/openvpn/server.conf

You don't need 'link0' anymore these days.
 
> I noticed this morning after upgrading 2 of my OpenVPN servers that
> unbound is failing to start because tun0 is not available on time. If I
> go back to start OpenVPN server from /etc/hostname.tun0 file everything
> works as expected.

Leaving the creation of the tun0 interface up to OpenVPN is never going to
work 100% of the time if other programs also depend on tun0 being present.

Have you considered following "Using an /etc/hostname.* file with persist-tun"
in /usr/local/share/doc/pkg-readmes/openvpn? And with that you could probably
also apply the config tweaks under "Running OpenVPN in chroot".



Re: Sun t5120 LDOMs

2020-11-09 Thread Stefan Sperling
On Mon, Nov 09, 2020 at 01:42:54PM +, John Gould wrote:
> Hi everyone, I am trying to set up a ldom on a sun t5120 machine running
> sparc64 6.8. This did work fine on 6.5. The problem I'm having is that once
> the machine is reset to use the openbsd bootmode  the machine hangs and
> asks for the root device. If one tries to answer this I get no way of
> entering
> sda which is the root device. Here is the ldom.conf file, the boot sequence
> with the hang and the factory-default dmesg. Can someone point me in the
> right direction on how to fix this so that I can install multiple ldom's?
> Does anyone know why it's not finding ( how to make it find ) the bootpath?

Here is the problem:

> mpi0 at pci8 dev 0 function 0 "Symbios Logic SAS1068E" rev 0x04
> vpci_intr_establish_cpu: pci_msi_setmsiq: err 6: unable to map interrupt at 
> msi 

6.8 has a bug where it enables message-signaled interrupts (MSI) on some
sparc64 machines which do not actually support MSI. Various devices then
fail to attach, including your disk controller mpi0.

This problem has been fixed after release. The fix is trivial, see below.

You could run -current instead of 6.8 to get this fix.

Or you could apply this patch to a 6.8-stable CVS checkout and build
your own kernel (since sparc64 doesn't have binary syspatches, you'd
be building your own kernels anyway for errata patches).

===
RCS file: /cvs/src/sys/arch/sparc64/dev/vpci.c,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- src/sys/arch/sparc64/dev/vpci.c 2020/06/25 21:43:41 1.31
+++ src/sys/arch/sparc64/dev/vpci.c 2020/10/24 05:07:47 1.32
@@ -1,4 +1,4 @@
-/* $OpenBSD: vpci.c,v 1.31 2020/06/25 21:43:41 jmatthew Exp $  */
+/* $OpenBSD: vpci.c,v 1.32 2020/10/24 05:07:47 jmatthew Exp $  */
 /*
  * Copyright (c) 2008 Mark Kettenis 
  *
@@ -273,6 +273,8 @@
 
/* One eq per cpu, limited by the number of eqs. */
num_eq = min(ncpus, getpropint(sc->sc_node, "#msi-eqs", 36));
+   if (num_eq == 0)
+   return;
 
if (OF_getprop(sc->sc_node, "msi-address-ranges",
msi_addr_range, sizeof(msi_addr_range)) <= 0)



Re: Support of the AX1650 card

2020-11-04 Thread Stefan Sperling
On Wed, Nov 04, 2020 at 06:57:38PM -0500, Ashton Fagg wrote:
> yul3n.f...@protonmail.com writes:
> 
> > Sorry I think I had a problem with my previous message which appeared
> > to be blank.  I plan to buy a laptop with an AX1650 wifi card, which
> > isn't marked as compatible with the iwx driver. However, it is, in
> > fact, a AX200, which is compatible with this driver, with a different
> > driver for Windows. So I wanted to know if it could work and someone
> > had tested it.  Thanks.
> 
> Telling us what model laptop might trigger more responses.

If you get us the output of 'pcidump -v' from such a machine then adding
support for the card should not be very difficult.

Unfortunately there is not just one "AX1650" card. There are several devices
using that name with some variations. Some of these devices will require
firmware to be added to the iwx-firmware package.

But it looks like all AX1650 variants are essentially AX201 devices.
So the driver code should work with little or no modifications once the
device ID is recognized and the correct firmware gets loaded.



Re: ifconfig bwi0 - no such interface

2020-09-13 Thread Stefan Sperling
On Sun, Sep 13, 2020 at 05:45:25PM -, elk_aide wrote:
> Hello list, how are you doing?  
> 
>   
> 
> I just installed a current OpenBSD snapshot and am having trouble using the
> Wifi.  
> 
> I already downloaded and installed the bwi-firmware, as that was one of the
> ones displayed on boot as a required one.  
> 
> Now if I try to use the device, as in 'ifconfig bwi0 scan' I get 'ifconfig: no
> such interface'.  
> 
> In dmesg I found the line  
> 
> 'bwi0 at pci10 dev0 function 0 "Broadcom BCM4331" rev 0x02: disabled' .  
> 
>   
> 
> What is happening there? How can I 'enable' the device?  

You cannot. There is no actual driver code for chip 4331 chips.

See the bottom of the bwi(4) man page:

CAVEATS
[...]
 The BCM4331 chip isn't supported by this driver but the driver disables
 the chip if detected, since some buggy EFI revisions found in 2011-2012
 Macs leave the chip enabled, causing it to emit spurious interrupts when
 the shared interrupt line is enabled.



Re: Problems with iwn wireless networking

2020-08-15 Thread Stefan Sperling
On Sat, Aug 15, 2020 at 09:14:48AM +0100, Julian Smith wrote:
> I'm seeing fairly frequent (e.g. more than daily) failures from an iwn0
> wireless network device, on a Lenovo X230.
> 
> dmesg|grep iwn shows:
> 
> iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi, 
> MIMO 2T2R, MoW, address a4:4e:31:43:f1:60
> iwn0: fatal firmware error
> iwn0: fatal firmware error
> iwn0: fatal firmware error
> iwn0: fatal firmware error
> iwn0: fatal firmware error
> iwn0: fatal firmware error
> iwn0: fatal firmware error
> iwn0: device timeout
> iwn0: device timeout
> iwn0: fatal firmware error
> iwn0: fatal firmware error
> iwn0: fatal firmware error
> iwn0: fatal firmware error
> iwn0: fatal firmware error
> iwn0: fatal firmware error
> iwn0: fatal firmware error
> iwn0: device timeout
> iwn0: fatal firmware error
> iwn0: fatal firmware error
> 
> Uptime is 6 days, so this is several failures per day on average.
> 
> iwn(4) DIAGNOSTICS says that these two types of error 'should not
> happen'.
> 
> Is here anything i can do about this? The machine is a Lenovo X230.
> 
> Or is there alternative wireless hardware that i install instead that
> is known to be reliable?
> 
> Full dmesg is below. My kernel has a patch from visa@ to reduce gdb
> uninterruptible wait problem (see 'gdb in uninterruptible wait' thread
> on misc), but is otherwise vanilla 6.7.

Could you try -current to see if the issue is still present there?

On 6.7, does forcing 11a or 11g mode work around this? For example:
ifconfig iwn0 mode 11g



Re: Intel AX200 Stopped Working on Latest Snapshot

2020-08-02 Thread Stefan Sperling
On Sun, Aug 02, 2020 at 11:58:26AM +0200, Stefan Sperling wrote:
> On Sat, Aug 01, 2020 at 09:16:55PM -0700, Bobby Reynolds wrote:
> > Hi Misc!
> > 
> > Just purchased an Intel AX200 so I could try out the new support in 6.7.
> > First and foremost, many thanks to those working on the wifi stack :)
> > 
> > I ran into some firmware issues with the 6.7 release, but I saw some
> > relevant entries in the -current changelog, and the snapshot from
> > Monday worked quite well! Unfortunately, after running sysupgrade this
> > afternoon my iwx0 device is no longer working. It shows up in dmesg but
> > not in ifconfig output, and I don't have network connectivity.
> > 
> > Any tips on how I might further debug the issue? I'm rather new to
> > OpenBSD but quite comfortable with debugging and digging into source
> > code.
> 
> > "Intel Wi-Fi 6 AX200" rev 0x1a at pci1 dev 0 function 0 not configured
> 
> I needed to tweak the iwx device matching code for AX201 because Intel
> is playing silly games with PCI product IDs.
> 
> Please send me the output of pcidump -vvv so I can make sure that
> your device is properly detected again.

Nevermind, after taking another close look at the Linux code I could
already commit a fix. So please compile a kernel from -current or wait
for a future snapshot. Your device should then work again.

In case of AX201 we need to be careful about which devices are matched by
the driver because there are technical differences such as which firmware
image is required. In addition to matching the PCI product ID, the driver 
must also match the PCI subsystem product ID against a table of known values.

For consistency I wrote similar matching code for AX200 devices, and it
correctly matches my AX200 device.

But in the AX200 case, the Linux driver uses subsystem product IDs only for
marketing purposes: It makes the operating system advertise some AX200 devices
with distinct trademarked names. There are no technical differences so we can
just go back to matching any AX200 device as we did before.

Sorry about the breakage.
Going forward, I'll try to keep in mind that some things drivers written
by vendors will do are not done for technical reasons...



Re: Intel AX200 Stopped Working on Latest Snapshot

2020-08-02 Thread Stefan Sperling
On Sat, Aug 01, 2020 at 09:16:55PM -0700, Bobby Reynolds wrote:
> Hi Misc!
> 
> Just purchased an Intel AX200 so I could try out the new support in 6.7.
> First and foremost, many thanks to those working on the wifi stack :)
> 
> I ran into some firmware issues with the 6.7 release, but I saw some
> relevant entries in the -current changelog, and the snapshot from
> Monday worked quite well! Unfortunately, after running sysupgrade this
> afternoon my iwx0 device is no longer working. It shows up in dmesg but
> not in ifconfig output, and I don't have network connectivity.
> 
> Any tips on how I might further debug the issue? I'm rather new to
> OpenBSD but quite comfortable with debugging and digging into source
> code.

> "Intel Wi-Fi 6 AX200" rev 0x1a at pci1 dev 0 function 0 not configured

I needed to tweak the iwx device matching code for AX201 because Intel
is playing silly games with PCI product IDs.

Please send me the output of pcidump -vvv so I can make sure that
your device is properly detected again.



Re: OpenBSD and HP ProBook 445 G7

2020-07-20 Thread Stefan Sperling
On Mon, Jul 20, 2020 at 02:14:17PM +0800, Tito Mari Francis Escaño wrote:
> Good day to everyone at misc.
> Has anybody tried tried checking how OpenBSD worked with HP ProBook 445 G7
> with Ryzen 5 or 7 4000 and Intel AX200 WLAN card?

AX200 wifi will work. I would recommend -current for best results.



Re: athn(4): hidenwid?

2020-07-16 Thread Stefan Sperling
On Thu, Jul 16, 2020 at 11:10:58AM +0200, Stefan Sperling wrote:
> Line 1927 of 
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net80211/ieee80211_input.c?annotate=1.218
> 
> This code runs before a response is generated for a probe request and it
> should ensure that a probe request is only generated if the SSID matches.
> 
> The next step would be to find out how this check is being bypassed in
> your case.

Nevermind, I have found the problem.

I moved the HIDENWID flag to a different variable some time ago:
[[[
CVSROOT:/cvs
Module name:src
Changes by: s...@cvs.openbsd.org2019/05/12 12:12:38

Modified files:
sbin/ifconfig  : ifconfig.8 
sys/dev/ic : if_wi.c 
sys/net80211   : ieee80211_input.c ieee80211_ioctl.c 
 ieee80211_ioctl.h ieee80211_output.c 
 ieee80211_var.h 

Log message:
Fix 'ifconfig nwflags; These flags ended up overlapping with other flags
in ieee80211com's ic_flags because we haven't been paying attention to
them (they're not in the same place in the code and hence easy to miss).
Move them to a dedicated variable to avoid this problem in the future.

Add a new 'stayauth' nwflag which can be set to let net80211 ignore
deauth frames. This can be useful when deauth frames are being
persistently spoofed by an attacker. Idea from beck@

ok beck@ phessler@
]]]

There is some use of the HIDENWID flag which I missed in this conversion.
This patch should fix it.

diff b38ea36846c22ecbc2e7394f8dcf015e2b6a523f /usr/src
blob - 8942bc3b47923fe0d78a4435b181777069b2a119
file + sys/dev/ic/bwfm.c
--- sys/dev/ic/bwfm.c
+++ sys/dev/ic/bwfm.c
@@ -1959,7 +1959,7 @@ bwfm_hostap(struct bwfm_softc *sc)
memset(join.assoc.bssid, 0xff, sizeof(join.assoc.bssid));
bwfm_fwvar_cmd_set_data(sc, BWFM_C_SET_SSID, , sizeof(join));
bwfm_fwvar_var_set_int(sc, "closednet",
-   (ic->ic_flags & IEEE80211_F_HIDENWID) != 0);
+   (ic->ic_userflags & IEEE80211_F_HIDENWID) != 0);
 }
 #endif
 
blob - 0cea2f80840c2b7bdbbf2dd7de3d83e3beabc7fa
file + sys/dev/ic/rt2560.c
--- sys/dev/ic/rt2560.c
+++ sys/dev/ic/rt2560.c
@@ -1588,7 +1588,7 @@ rt2560_tx_bcn(struct rt2560_softc *sc, struct mbuf *m0
mtod(m0, uint8_t *) +
sizeof (struct ieee80211_frame) +
8 + 2 + 2 +
-   ((ic->ic_flags & IEEE80211_F_HIDENWID) ?
+   ((ic->ic_userflags & IEEE80211_F_HIDENWID) ?
1 : 2 + ni->ni_esslen) +
2 + min(ni->ni_rates.rs_nrates, IEEE80211_RATE_SIZE) +
2 + 1 +
blob - 7170cb0085cbb2f47ff2d02d204f5706f4eb22a2
file + sys/dev/ic/rt2661.c
--- sys/dev/ic/rt2661.c
+++ sys/dev/ic/rt2661.c
@@ -2935,7 +2935,7 @@ rt2661_prepare_beacon(struct rt2661_softc *sc)
RT2661_HW_BEACON_BASE0 + 24 +
sizeof (struct ieee80211_frame) +
8 + 2 + 2 +
-   ((ic->ic_flags & IEEE80211_F_HIDENWID) ?
+   ((ic->ic_userflags & IEEE80211_F_HIDENWID) ?
1 : 2 + ni->ni_esslen) +
2 + min(ni->ni_rates.rs_nrates, IEEE80211_RATE_SIZE) +
2 + 1 +
blob - 098aa9bce19481ce09676ce3c4fc0040f14c9b93
file + sys/net80211/ieee80211_input.c
--- sys/net80211/ieee80211_input.c
+++ sys/net80211/ieee80211_input.c
@@ -1937,7 +1937,7 @@ ieee80211_recv_probe_req(struct ieee80211com *ic, stru
return;
}
/* refuse wildcard SSID if we're hiding our SSID in beacons */
-   if (ssid[1] == 0 && (ic->ic_flags & IEEE80211_F_HIDENWID)) {
+   if (ssid[1] == 0 && (ic->ic_userflags & IEEE80211_F_HIDENWID)) {
DPRINTF(("wildcard SSID rejected"));
ic->ic_stats.is_rx_ssidmismatch++;
return;




Re: athn(4): hidenwid?

2020-07-16 Thread Stefan Sperling
On Thu, Jul 16, 2020 at 06:19:40AM +, Mogens Jensen wrote:
> I'm not trying to start a discussion on whether hiding the ESSID is
> ridiculous or not, I'm just testing different things, so I know which
> features work and which don't.

Thanks for digging into this. Since there are no automated tests for
the wifi stack it is difficult to determine whether the code is fully
correct. And regressions do sometimes occur. So getting test reports
such as this is very valuable.

There is this chunk of code which is supposed to catch a wrong SSID and
it does take "hidenwid" mode into account:

/* SSID element is mandatory */
if (ssid == NULL || ssid[1] > IEEE80211_NWID_LEN) {
DPRINTF(("invalid SSID element\n"));
return;
}
/* check that the specified SSID (if not wildcard) matches ours */
if (ssid[1] != 0 && (ssid[1] != ic->ic_bss->ni_esslen ||
memcmp([2], ic->ic_bss->ni_essid, ic->ic_bss->ni_esslen))) {
DPRINTF(("SSID mismatch\n"));
ic->ic_stats.is_rx_ssidmismatch++;
return;
}
/* refuse wildcard SSID if we're hiding our SSID in beacons */
if (ssid[1] == 0 && (ic->ic_flags & IEEE80211_F_HIDENWID)) {
DPRINTF(("wildcard SSID rejected"));
ic->ic_stats.is_rx_ssidmismatch++;
return;
}

Line 1927 of 
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net80211/ieee80211_input.c?annotate=1.218

This code runs before a response is generated for a probe request and it
should ensure that a probe request is only generated if the SSID matches.

The next step would be to find out how this check is being bypassed in
your case. Are you really sure that probe responses are sent to the MAC
address of clients which do not already know the correct SSID? The patch
below will make the kernel print the MAC addresses of rejected clients
to 'dmesg':

diff b38ea36846c22ecbc2e7394f8dcf015e2b6a523f /usr/src
blob - 098aa9bce19481ce09676ce3c4fc0040f14c9b93
file + sys/net80211/ieee80211_input.c
--- sys/net80211/ieee80211_input.c
+++ sys/net80211/ieee80211_input.c
@@ -1932,13 +1932,15 @@ ieee80211_recv_probe_req(struct ieee80211com *ic, stru
/* check that the specified SSID (if not wildcard) matches ours */
if (ssid[1] != 0 && (ssid[1] != ic->ic_bss->ni_esslen ||
memcmp([2], ic->ic_bss->ni_essid, ic->ic_bss->ni_esslen))) {
-   DPRINTF(("SSID mismatch\n"));
+   printf("SSID mismatch from %s\n",
+   ether_sprintf((u_int8_t *)wh->i_addr2));
ic->ic_stats.is_rx_ssidmismatch++;
return;
}
/* refuse wildcard SSID if we're hiding our SSID in beacons */
if (ssid[1] == 0 && (ic->ic_flags & IEEE80211_F_HIDENWID)) {
-   DPRINTF(("wildcard SSID rejected"));
+   printf("wildcard SSID rejected from %s\n",
+   ether_sprintf((u_int8_t *)wh->i_addr2));
ic->ic_stats.is_rx_ssidmismatch++;
return;
}



Re: An Athn ar9280 client seems to require cold boots of late?

2020-07-06 Thread Stefan Sperling
On Mon, Jul 06, 2020 at 11:10:13AM +, Kevin Chadwick wrote:
> With this patch I have been able to bring the device down and back up with a 
> subsequently successful dhclient and http download.
> 
> Annoying how quirky and poorly documented, chips often are!
> 
> Thank You
> 

Thanks for confirming. The fix has been committed :)



Re: Prohibit WiFi interface from transmitting?

2020-07-05 Thread Stefan Sperling
On Sun, Jul 05, 2020 at 08:37:40PM +, Mogens Jensen wrote:
> I've installed OpenBSD 6.7 on a system that have an athn(4) wireless
> network adapter. Before setting up this device, I wanted to verify the
> configuration of pf, unbound etc. which required the interface to have
> an IP address, so I added the following line to /etc/hostname.athn0:
> 
> inet 192.168.10.1 255.255.255.0
> 
> This enabled the interface, which allowed pf, unbound etc. to start:
> 
> # ifconfig athn0
> athn0: flags=8843 mtu 1500
>   lladdr XX:XX:XX:XX:XX:XX
>   index 4 priority 4 llprio 3
>   groups: wlan
>   media: IEEE802.11 autoselect (DS1)
>   status: no network
>   ieee80211: nwid ""
>   inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255
> 
> However, it also automatically made the interface start scanning:
> 
> # netstat -W athn0 | grep scans
> 1 active scans started
> 0 passive scans started
> 
> Is it possible to configure the athn0 interface with an IP address, but
> prohibit any kind of wireless communication?

Setting an IP address will implicitly mark the interface UP.
This is long-standing behaviour and unlikely to change.

And when a wifi interfaces is marked UP it will search for access points.

Since you don't have an nwid configured, what will happen is:

1) The device will send a probe request with a wildcard SSID.
   Afterwards it will continue to listen for beacons indefinitely.

2) The device will receive beacons which are parsed by the kernel to
   populate the list of networks shown by 'ifconfig athn0 scan'.
   Because no nwid is configured no connection attempt will be made.
   (Note that this is new behaviour in OpenBSD 6.7. Before 6.7, the
   kernel would try to find an unencrypted network to connect to.)

It is impossible to exchange data frames with the system over wifi in
this unassociated state because any incoming data frames will be dropped.
So if that's your concern then there is no actual reason to worry.

> The reason for this is that I have to verify many systems with
> different configuration, which requires athn0 to be configured with an
> IP address. I want to do the verification and install patches before any
> wireless communication happens, as I can't guarantee that none of the
> devices within wireless range are malicious.

As a workaround you could add 'down' to your hostname.if file after
configuring the IP:

inet 192.168.10.1 255.255.255.0
down

That will disable the device after IP configuration. The address will
remain configured and the interface will remain inactive until marked UP.
Though I cannot tell if this would satisfy your verification process.



Re: An Athn ar9280 client seems to require cold boots of late?

2020-07-05 Thread Stefan Sperling
On Mon, Jun 29, 2020 at 12:09:12PM +, Kapfhammer, Stefan wrote:
> Hi,
> 
> I am using exactly the same WLE-200NX wifi card in an APU2B4. I have a 
> BlackBerry KeyONE
> running at Android 8.1 / Version ABT975 which I use as hotspot for the APU2.
> 
> After setting athn0 down, it is impossible to establish the connection - 
> without further intervention -
> a second time.
> 
> What helps is:
> 
> First:
> #/bin/sh
> /sbin/ifconfig athn0
> /sbin/ifconfig athn0 down -inet -inet6 -join bbk1 -wpakey -chan -bssid
> /sbin/ifconfig athn0
> 
> Second:
> Disabling the hotspot on bbk1 and re-enabling it
> 
> Third:
> sh -x /etc/netstart athn0
> 
> This prevents to do a coldboot on the APU2 - reducing downtime.
> AND: It works reliably everytime since month!
> 

In case you missed it, a fix was proposed on the bugs@ list on Friday:
https://marc.info/?l=openbsd-bugs=159380123409160=2
The same patch is copied below.

If anyone else could confirm that this makes athn(4) work again as
a client against a WPA2 AP then I will commit this.

diff refs/heads/master refs/heads/athn-ccmpfix
blob - 3a28d87bc88a0e7b9ed6c873bd7a07682cc91a0b
blob + 1d739529d7d214bea314e50e847594dc01021a41
--- sys/dev/ic/ar5008.c
+++ sys/dev/ic/ar5008.c
@@ -811,12 +811,20 @@ ar5008_ccmp_decap(struct athn_softc *sc, struct mbuf *
/* Sanity checks to ensure this is really a key we installed. */
entry = (uintptr_t)k->k_priv;
if (k->k_flags & IEEE80211_KEY_GROUP) {
-   if (k->k_id > IEEE80211_WEP_NKID ||
+   if (k->k_id >= IEEE80211_WEP_NKID ||
entry != k->k_id)
return 1;
-   } else if (entry != IEEE80211_WEP_NKID +
-   IEEE80211_AID(ni->ni_associd))
-   return 1;
+   } else {
+#ifndef IEEE80211_STA_ONLY
+   if (ic->ic_opmode == IEEE80211_M_HOSTAP) {
+   if (entry != IEEE80211_WEP_NKID +
+   IEEE80211_AID(ni->ni_associd))
+   return 1;
+   } else
+#endif
+   if (entry != IEEE80211_WEP_NKID)
+   return 1;
+   }
 
/* Check that ExtIV bit is set. */
if (!(ivp[3] & IEEE80211_WEP_EXTIV))
blob - 40725b02c43b54e10a87de333acdfd3b8270534d
blob + f7aa77ba15cae787a42fdbffb8a9d9cd2d0226d2
--- sys/dev/ic/athn.c
+++ sys/dev/ic/athn.c
@@ -1037,12 +1037,17 @@ athn_set_key(struct ieee80211com *ic, struct ieee80211
}
 
if (!(k->k_flags & IEEE80211_KEY_GROUP)) {
-   entry = IEEE80211_WEP_NKID + IEEE80211_AID(ni->ni_associd);
+#ifndef IEEE80211_STA_ONLY
+   if (ic->ic_opmode == IEEE80211_M_HOSTAP)
+   entry = IEEE80211_WEP_NKID + 
IEEE80211_AID(ni->ni_associd);
+   else
+#endif
+   entry = IEEE80211_WEP_NKID;
if (entry >= sc->kc_entries - IEEE80211_WEP_NKID)
return ENOSPC;
} else {
entry = k->k_id;
-   if (entry > IEEE80211_WEP_NKID)
+   if (entry >= IEEE80211_WEP_NKID)
return ENOSPC;
}
k->k_priv = (void *)entry;
@@ -3056,10 +3061,6 @@ athn_init(struct ifnet *ifp)
else
athn_config_pcie(sc);
 
-   /* Reset HW key cache entries. */
-   for (i = 0; i < sc->kc_entries; i++)
-   athn_reset_key(sc, i);
-
ops->enable_antenna_diversity(sc);
 
 #ifdef ATHN_BT_COEXISTENCE
@@ -3086,6 +3087,10 @@ athn_init(struct ifnet *ifp)
/* Enable Rx. */
athn_rx_start(sc);
 
+   /* Reset HW key cache entries. */
+   for (i = 0; i < sc->kc_entries; i++)
+   athn_reset_key(sc, i);
+
/* Enable interrupts. */
athn_enable_interrupts(sc);
 
@@ -3121,7 +3126,7 @@ athn_stop(struct ifnet *ifp, int disable)
 {
struct athn_softc *sc = ifp->if_softc;
struct ieee80211com *ic = >sc_ic;
-   int qid;
+   int qid, i;
 
ifp->if_timer = sc->sc_tx_timer = 0;
ifp->if_flags &= ~IFF_RUNNING;
@@ -3158,6 +3163,10 @@ athn_stop(struct ifnet *ifp, int disable)
AR_WRITE_BARRIER(sc);
athn_set_rxfilter(sc, 0);
athn_stop_rx_dma(sc);
+
+   /* Reset HW key cache entries. */
+   for (i = 0; i < sc->kc_entries; i++)
+   athn_reset_key(sc, i);
 
athn_reset(sc, 0);
athn_init_pll(sc, NULL);



Re: An Athn ar9280 client seems to require cold boots of late?

2020-06-29 Thread Stefan Sperling
On Sun, Jun 28, 2020 at 03:43:09PM -0600, Austin Hook wrote:
> 
> I have a similar problem with the 6.7 release which I just installed today 
> on an 8Tb drive I'm using with my older ASUS laptop.
> 
> athn0 at pci3 dev 0 function 0 "Atheros AR9285" rev 0x01: apic 2 int 17
> athn0: AR9285 rev 2 (1T1R), ROM rev 13, address 74:f0:6d:7a:42:7f
> 
> Can't seem to shake it with a cold boot.

Even if "cold boot" helped, the problem would still be narrowed down much
further before it could be addressed. There's no obvious code change anyone
could make based on the knowledge that something only works after a cold boot.

> However no matter what I do I can't get a connection to my farmhouse 
> wireless router.  It's a DIR822 Dlink.  Of course I know that's a low end 
> router.  Recently they recommended a firmware upgrade, and since then I 
> found that I was unable to set it up for no password, and had to add one, 
> and then add that password to all the other devices in the house.

There is one interop problem in 6.7 which has been fixed in -current
by reverting a change which was committted between 6.6 and 6.7:
https://marc.info/?l=openbsd-cvs=159100149411516=2
Perhaps that applies to your situation? Could you check if a -current
bsd.rd kernel is able to connect to this problematic AP?



Re: Atheros AR9462 Wifi Card Support

2020-05-28 Thread Stefan Sperling
On Thu, May 28, 2020 at 12:54:27PM +, MrPhyber wrote:
> Hello everyone,
> I just installed OpenBSD on my laptop, everything works except for the
> wifi card that happens to be an Atheros AR9462. Are there any future
> plans to support this card? For the moment I am using a wifi usb dongle.

OpenBSD's athn(4) doesn't support many devices, unfortunately.
Only older 2-antenna variants are supported at present.
See the athn man page for a list of supported chips.

Adding support for more chips requires someone with skills and time and
dedication to fix and extend the driver.



Re: Liksys pci wireless card

2020-05-27 Thread Stefan Sperling
On Wed, May 27, 2020 at 08:09:29AM +, man Chan wrote:
> Hello,
> I tried to setup my Linksys WLAN (Ralink RT2560) as access point with 
> 
> mediaopt hostap
> nwid mynwid wpakey mywpakey
> inet 192.168.2.1 255.255.255.0
> 
> When I ifconfig ral0,  I got status: no network.  Did I missing something to 
> make it work or this card cannot config as hostap ?  any idea ?
> 
> Thanks.
> 
> Clarence
> 
> 
> 

Try setting the channel explicitly:

mediaopt hostap mode 11g chan 1
nwid mynwid wpakey mywpakey
inet 192.168.2.1 255.255.255.0

This avoids an automatic search for a channel to use.
The interface will not come up before a channel is set.



Re: i386 kernel relinking

2020-05-19 Thread Stefan Sperling
On Fri, Apr 10, 2020 at 10:25:14AM -0400, Nick Holland wrote:
> On 2020-04-10 10:10, Stefan Sperling wrote:
> > On Fri, Apr 10, 2020 at 09:35:16AM -0400, Nick Holland wrote:
> > FWIW, my soekris net5501 with 256MB of RAM and 512MB swap does manage
> > to relink a kernel (on 6.6 + syspatches).
> 
> Whoops.  Guess I should have mentioned, that was -current, as of
> yesterday 
> OpenBSD 6.7-beta (GENERIC.MP) #110: Thu Apr  9 01:20:52 MDT 2020
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> real mem  = 334970880 (319MB)
> avail mem = 313077760 (298MB)
> 
> and probably a couple weeks ago for the real (old) hw.
> 
> I'm curious if your Soekris can handle 6.7-beta.
> 
> Nick.

It's been fixed in 6.7 release!

This was indeed a problem on my alix and soekris machines for a while.
And I could also reproduce it in a 6.7-beta low memory VM as you did.

I attempted to debug ld.lld for a while but eventually gave up (debugging
the linker is quite painful).

I did not come to any conclusion but did notice that ld.lld uses mmap to 
write ELF data to the output file. That file always ended up being corrupt
under low memory conditions. The old ld.bfd linker uses stdio and worked OK.

With 6.7 kernel relinking with little amounts of memory suddenly started
working again. To make sure I'm not dreaming I bisected the commit which
fixed it.

Turns out this problem was fixed by beck@ in the commit below.
I can even relink kernels on i386 in 64MB of RAM now. Didn't test lower
than that.  Case closed. Just upgrade to 6.7 and it'll be fine :-)

CVSROOT:/cvs
Module name:src
Changes by: b...@cvs.openbsd.org2020/04/28 20:25:48

Modified files:
sys/kern   : vfs_bio.c 

Log message:
Ensure that if we are doing a delayed write with a NOCACHE buffer, we
clear the NOCACHE flag, since if we are doing a delayed write the buffer
must be cached or it is thrown away when the "write" is done.
fixes vnd on mfs regress tests.

ok kettenis@ deraadt@



Re: ieee80211 panic on athn reconfig

2020-05-03 Thread Stefan Sperling
On Fri, Apr 17, 2020 at 12:08:39PM +0200, Jan Stary wrote:
> This is current/i386 on an ALIX (dmesg below) with
> 
>   athn0 at pci0 dev 12 function 0 "Atheros AR9280" rev 0x01: irq 9
>   athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:01:d6:86
> 
> # cat hostname.athn0
> inet 192.168.33.1 255.255.255.0 NONE
> media autoselect mode 11g mediaopt hostap chan 2
> nwid stare.cz wpakey hovnoPrdel123
> 
> After changing the password, or the channel, or the mode, and doing
> 
> # sh /etc/netstart athn0
> 
> the machine reproducibly panics (cereal script below).
> 
> I have no idea why it panics in ieee80211_encrypt().
> It happens both with clients associated and not.
> 
> Is this known with athn(4)?
> How can I help debug this?
> 
>   Jan
> 
> 
> ddb> show panic
> ieee80211_encrypt: key unset for sw crypto: 0
> 
> ddb> trace
> db_enter() at db_enter+0x4
> panic(d0b83788) at panic+0xcc
> ieee80211_encrypt(d194e030,d195bc00,d194eb00) at ieee80211_encrypt+0x70
> ar5008_tx(d194e000,d195bc00,d19a,2) at ar5008_tx+0x9a
> ar5008_swba_intr(d194e000) at ar5008_swba_intr+0x238
> ar5008_intr(d194e000) at ar5008_intr+0x12f
> intr_handler(f3b1d67c,d1945480) at intr_handler+0x18
> Xintr_legacy9_untramp() at Xintr_legacy9_untramp+0xf7
> end of kernel

Are you using clients which use powersave mode, such as phones?

This trace goes through ar5008_swba_intr(). The only way to get into
ar5008_tx() from there is when group-addressed frames are queued on the
powersave queue of the AP (ic_bss->ni_savedq).

I cannot see this queue being purged anywhere when the interface goes down.
So it seems what happened is that a stale frame was sitting on this queue
and a fatal transmit attempt occurred when the interface came back up after
being re-configured.

Can you please try this diff?

The same panic and trace has also been reported to me by Ted Patterson.

diff ffca677e9e7ca9efd316fa2f2b6572b193c50cf8 /usr/src
blob - f6349c70279687b18ce89f670b732a62f3696271
file + sys/net80211/ieee80211_node.c
--- sys/net80211/ieee80211_node.c
+++ sys/net80211/ieee80211_node.c
@@ -1595,6 +1595,10 @@ ieee80211_node_cleanup(struct ieee80211com *ic, struct
free(ni->ni_unref_arg, M_DEVBUF, ni->ni_unref_arg_size);
ni->ni_unref_arg = NULL;
ni->ni_unref_arg_size = 0;
+
+#ifndef IEEE80211_STA_ONLY
+   mq_purge(>ni_savedq);
+#endif
 }
 
 void
@@ -2047,7 +2051,7 @@ ieee80211_free_allnodes(struct ieee80211com *ic, int c
splx(s);
 
if (clear_ic_bss && ic->ic_bss != NULL)
-   ieee80211_node_cleanup(ic, ic->ic_bss); /* for station mode */
+   ieee80211_node_cleanup(ic, ic->ic_bss);
 }
 
 void



Re: WLAN throughput less 10Mb/s

2020-04-23 Thread Stefan Sperling
On Thu, Apr 23, 2020 at 02:52:09AM -0300, Anatoli wrote:
> How do the same drivers work in Linux? Can't "we" "just" "copy" the code
> from there?

That's already what we are doing.

But porting (what you call "just copying") code is a lot of work, too.
This stuff needs a lot of attention to detail to work right and there
is already too much divergance between any of these kernels for cp -R
to produce a useful result. And apart from a working wifi device you
would like the code that runs on your CPU to be audited as well, no?

> Or does the GPL licensing absolutely prevents from analyzing
> Linux code and using their implementation details?

Linux has some BSD-licensed drivers and we are already porting them.
A lot of iwm(4), iwx(4), and bwfm(4) code came from Linux.

There's a plan to port ath10k code from Linux but that project is
stuck due to lack of time because there is too much to do.

This problem isn't specific to OpenBSD either.
I am getting regular email from people trying to port iwx(4) from OpenBSD
to FreeBSD, and not being able to get it to work even though the driver works
on OpenBSD.



Re: Updating a Nextcloud instance installed via package

2020-04-18 Thread Stefan Sperling
On Sat, Apr 18, 2020 at 12:20:34PM +0200, Unicorn wrote:
> > I keep a nightly backup of the database (postgres in my case),
> > upgrade packages and trigger nextcloud's upgrade process via HTTPS
> > on the nextcloud login page. This process has not failed for me so
> > far. Except when postgres had a version bump as well with some
> > incompatible DB format changes, and I stupidly upgraded postgres
> > without checking whether my DB backup was current. Turned out it was
> > a day or so behind. But I could restore this DB backup to a newly
> > created postgres database and nextcloud kept working.
> 
> Thanks a ton for the input, I will give this procedure a shot!
> 
> Since I am also using postgres and don't have much experience working
> with databases, I would appreciate advice on backing up postgres. Do
> you use the syntax from the NC docs (
> https://docs.nextcloud.com/server/18/admin_manual/maintenance/backup.html#backup-database
> ) with something like a cron job, or would you advise something
> different/additional?

For the DB see /usr/local/share/doc/pkg-readmes/postgresql-server
which has an upgrade section that contains dump/load commands to use.

My nextcloud data files are backed up with rsync over SSH.



Re: Updating a Nextcloud instance installed via package

2020-04-18 Thread Stefan Sperling
On Sat, Apr 18, 2020 at 08:06:10AM +0200, Unicorn wrote:
> Hello,
> 
> I have a running installation of Nextcloud, installed via the OpenBSD
> package and set up according to the various pkg-readmes. The section
> about updating is kept very short, so I wanted to ask here before doing
> something unwise out of my lack of experience:
> 
> When trying to use the NC updater (after working around the chroot), it
> complains that there is an additional file in the directory, namely
> ".htaccess.dist". The installation also fails the integrity check
> (unrelated to upgrade), I assume because of modifications that were
> made by the maintainers. I am not aware of what these modifications are
> and whether they are needed for NC to run properly on OpenBSD, so I was
> wondering how the update process would work using "pkg-add -u" to
> simply update the package. Would that replace the entire directory, or
> does it just fetch the newest version of Nextcloud, after which I would
> just need to run `occ upgrade`? Is there a better, recommended way to
> update in this case?
> 
> I'd be very thankful for some guidance and advice before I accidentally
> break something or end up with a bad hack. :)

I keep a nightly backup of the database (postgres in my case), upgrade
packages and trigger nextcloud's upgrade process via HTTPS on the nextcloud
login page. This process has not failed for me so far. Except when postgres
had a version bump as well with some incompatible DB format changes, and I
stupidly upgraded postgres without checking whether my DB backup was current.
Turned out it was a day or so behind. But I could restore this DB backup to
a newly created postgres database and nextcloud kept working.



Re: ieee80211 panic on athn reconfig

2020-04-17 Thread Stefan Sperling
On Fri, Apr 17, 2020 at 12:08:39PM +0200, Jan Stary wrote:
> This is current/i386 on an ALIX (dmesg below) with
> 
>   athn0 at pci0 dev 12 function 0 "Atheros AR9280" rev 0x01: irq 9
>   athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:01:d6:86
> 
> # cat hostname.athn0
> inet 192.168.33.1 255.255.255.0 NONE
> media autoselect mode 11g mediaopt hostap chan 2
> nwid stare.cz wpakey hovnoPrdel123
> 
> After changing the password, or the channel, or the mode, and doing
> 
> # sh /etc/netstart athn0
> 
> the machine reproducibly panics (cereal script below).
> 
> I have no idea why it panics in ieee80211_encrypt().
> It happens both with clients associated and not.
> 
> Is this known with athn(4)?

No, but it is definitely a bug.

> How can I help debug this?

Could you try to find a short sequence of 'ifconfig athn0' commands that
will trigger it, instead of /etc/netstart? That would help me already. 



Re: WLAN throughput less 10Mb/s

2020-04-15 Thread Stefan Sperling
On Wed, Apr 15, 2020 at 06:45:26AM -0700, 0x6d6174 wrote:
> Hi everyone.
> 
> I'm running also an APU2 board with an Atheros wlan chipset:
> 
> athn0 at pci5 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 5 int 16
> athn0: AR9280 rev 2 (2T2R), ROM rev 22, address XX:XX:XX:XX:XX:XX
> 
> I also used an ALIX board with an Atheros wlan chipset (AR9280).
> >From OpenBSD 6.0 to 6.6 (-stable) (iirc OpenBSD 5.9 had a slightly better
> performance) the wlan performance didn't change for me. 
> 
> I use the following test setup:
> 
> PC <---   100mbps / 1gbps lan ---> ALIX / APU2 board <--- Atheros wlan --->
> Notebook
> 
> # cat /etc/hostname.athn0
> media autoselect mode 11g mediaopt hostap chan 3
> nwid test wpa wpakey wpasecret
> wpaprotos wpa2 wpaciphers ccmp wpagroupcipher ccmp powersave
> up
> 
> 
> For simplicity I disable pf and use a bridge interface that uses the lan and
> wlan interfaces. Also I always send files with scp from my PC to my notebook
> for performance measurements.

Thanks, this is interesting.

Can you try your test again without WPA?
OpenBSD's athn(4) driver does not offload crypto to hardware yet.
I suspect this explains your observations below.

> The ALIX board has a wlan throughput of about 2.4 - 3.2 mbps while the APU2
> has a wlan throughput of about 12 - 14 mbps. I noticed by running top -S,
> that if I transfer lets say a 1000MB file, then for both boards softnet has
> a CPU usage of 100%, thus I suspected that the wlan bandwidth for an Atheros
> chip correlates to the CPU usage of softnet (because the APU2 board has a
> better CPU it has a higher wlan throughput). If I send a 1000MB file from
> one lan interface to another lan interface, then softnet has a CPU usage of
> about 20% and the file transfer has a throughput of almost 1gbps. Thus I
> suspect the high CPU usage of softnet has something to do with the TX
> performance of the atheros driver implementation.
> 
> For a quick test I enabled pf and used traffic sharping to reduce the wlan
> troughput:
> queue std on "athn0" bandwidth 5M max 10M default
> 
> Now when I transfer a file softnet has a CPU usage of about 70-73% for the
> APU2 board (the wlan throughput is about 10 - 11 mbps).
> 
> Also I found an interesting performance report, that pfSense could reach
> about 90 mbps with the same hardware that I have (APU2 board with the same
> wlan card) see [1], unfortunately I don't have the time to verify it. If
> that's true, then the next step I want to do is a diff of the driver
> implementations and hopefully understand why pfSense has a much higher
> throughput.
> 
> [1]
> https://teklager.se/en/knowledge-base/compex-wle200nx-wle600vx-benchmark/
> 
> best regards,
> Mat
> 
> 
> 
> --
> Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
> 
> 



Re: WLAN throughput less 10Mb/s

2020-04-14 Thread Stefan Sperling
On Tue, Apr 14, 2020 at 11:37:24AM +0100, Kevin Chadwick wrote:
> On 2020-04-14 09:21, Stefan Sperling wrote:
> > Regarding other chipsets, if you want the fastest possible AP on OpenBSD
> > your best option right now is to get a bwfm(4) device, which offloads almost
> > all of its 802.11 operation into a firmware blob running in the embedded
> > system on the device.
> 
> Interesting.
> 
> BWFM(4)
> CAVEATS
>  The firmware is outdated and contains known vulnerabilities.
> 
> Any more information on the seriousness of these vulnerabilities?
> 
> I can probably look it up in CVS actually but figured it *may* be prudent of 
> me
> to highlight that caveat on the list explicitly, in any case.
 
I honestly don't know and don't really care. Even if we knew what publicly
known or unknown bugs linger in there, we couldn't do anything about it.
All we can really do is upgrade the firmware and hope for the best.

The same is true for the Intel wifi chips.

What's nice about athn(4) is that the full software stack from driver to
hardware is open source, including firmware for USB devices. So it's
possible to fix issues, though it can be quite hard to fix known bugs.
No firmware abstraction means the driver needs to deal with a lot of
complexity all by itself, i.e. problems that engineers at vendors with
proper testing equipment and low-level expertise tend to deal with.



Re: WLAN throughput less 10Mb/s

2020-04-14 Thread Stefan Sperling
On Mon, Apr 13, 2020 at 10:42:18PM +0200, Mario Theodoridis wrote:
> > Also, athn(4) does not support Tx aggregation yet, and 40 MHz channels are
> > not yet suppored either. In practice this means the driver won't be 
> > noticably
> > faster in 11n mode than it is in 11a/g modes. For now, I would recommend
> > using 11a mode if you want it to be as fast as possible.
> 
> Hmm, using
> media autoselect mode 11a mediaopt hostap
> nwid foo
> wpaprotos wpa2
> wpakey mysecret
> up
> 
> Brings the inteface up alright, but i don't see any 5 or 2.4 GHz signal with
> a Wifi analyzer nor can i connect.

The 'nwid' and 'wpakey' options should appear on the same line.

You don't need to specify 'wpaprotos wpa2' since this is the default.

> > is going to help when your channel is heavily used by one or more other
> > wifi networks. Ensure that your AP is running on a channel where no other
> > wifi networks can be seen in a scan.
> 
> The channel is available, but i am only using one antenna. I remember trying
> with both didn't help, though.

If you use 11n mode you must have 2 antennas connected for MIMO.
Otherwise it will perform rather badly since MIMO frames (MCS-8 to MCS-15)
are going to be lost.

> > > OpenBSD 6.6 (GENERIC.MP) #7: Thu Mar 12 11:55:22 MDT 2020
> > 
> > One way you could help is to keep following -current, upgrade a day or so
> > after any wifi-related commits happen, and letting us know if things are
> > better or worse compared to a previous snapshots.
> 
> I'm looking into that.
> 
> Meanwhile is there a mini PCI chipset that will do 54Mb or more in hostap
> mode?

54Mbit where? You're not going to see tcpbench displaying "54Mbps" on a
"54Mbit" AP if that's what you're expecting to see.
Typically "54 Mbit" refers to a specific modulation scheme (64-QAM with a
3/4 coding rate) used to transmit the data payload of an 802.11 frame.
But transmitting a frame involves a lot more than just sending payload data,
so user-visible data rates are much lower and depend on many factors.
In my experience tcpbench over 11a maxes out at around 20-30 Mbps on a
clean channel.

Regarding other chipsets, if you want the fastest possible AP on OpenBSD
your best option right now is to get a bwfm(4) device, which offloads almost
all of its 802.11 operation into a firmware blob running in the embedded
system on the device. So far, this is the only way to have an OpenBSD 11ac
AP (with the caveat that about the only OpenBSD wifi code you're running
is the code that handles WPA handshakes; everything else is offloaded).



Re: WLAN throughput less 10Mb/s

2020-04-13 Thread Stefan Sperling
On Mon, Apr 13, 2020 at 07:03:27PM +0200, Mario Theodoridis wrote:
> Hi everyone.
> 
> I'm running a APU2 board with an Atheros wlan chipset.
> I've been plagued by rather slow WLAN throughput rates < 10Mb/s.
> Is that normal or not. If not, how would i go about debugging this?
> Any other info i should provide?

Is this a new problem or has it always been like this for you?

> Here's an ifconfig
> athn0: flags=8943 mtu 1500

There are several known performance issues with athn(4).

One is that the device seems unable to send frames at the upper frame data
rates. At least in my environment the hardware throws Tx errors when it is
asked to send such frames. I don't understand where this is coming from.
Automatic rate selection works around it by detecting that some rates don't
work and then not using them. But it means we're only using slower rates
than the hardware is supposed to be able to transmit frames with.

Then are other factors that make things even worse:

I am not certain if the block ack Rx logic is correctly working in this driver.
It seems the device will only send block ack frames when its block ack window
is full (i.e. every 64 frames) or when the client asks for a block ack frame.
As far as I understand a block ack should be sent after every aggregate frame
which gets received, but this is not the case. This can lead to low throughput
for TCP due to redundantly re-transmitted packets or dropped packets.
This needs to be debugged and better understood before something can be done.

And our automatic rate selection has some performance issues of its own.

Also, athn(4) does not support Tx aggregation yet, and 40 MHz channels are
not yet suppored either. In practice this means the driver won't be noticably
faster in 11n mode than it is in 11a/g modes. For now, I would recommend
using 11a mode if you want it to be as fast as possible.
 
I do want to fix all of these issues, but it will take time and help
would be very welcome.

Another important factor is your RF environment. No amount of bug fixing
is going to help when your channel is heavily used by one or more other
wifi networks. Ensure that your AP is running on a channel where no other
wifi networks can be seen in a scan.

> OpenBSD 6.6 (GENERIC.MP) #7: Thu Mar 12 11:55:22 MDT 2020

One way you could help is to keep following -current, upgrade a day or so
after any wifi-related commits happen, and letting us know if things are
better or worse compared to a previous snapshots.



Re: i386 kernel relinking

2020-04-10 Thread Stefan Sperling
On Fri, Apr 10, 2020 at 09:35:16AM -0400, Nick Holland wrote:
> Question about kernel randomization and relinking...
> 
> It seems to take a fair amount of RAM, at least for systems that
> are forced to run i386.  And I mean real RAM -- swap doesn't seem
> to cut it.  
> 
> I discovered that several machines I was intending on using for
> minimal purposes just couldn't complete relinking.  So I built a
> VM and started playing with the RAM.
> 
> Built with 1G RAM, default was a 1.2G swap, worked fine.
> Reduced to 256MB RAM, Kernel failed to relink.  As with my old
> junk.
>
> The magic number seemed to be between 320MB (failed) and 384MB 
> (worked) of RAM.  Ok, fine.  

FWIW, my soekris net5501 with 256MB of RAM and 512MB swap does manage
to relink a kernel (on 6.6 + syspatches).

# ls -l relink.log
-rw-r--r--  1 root  wheel  -  507B Apr 10 13:33 relink.log
# cat relink.log   
(SHA256) /bsd: OK
LD="ld" LDFLAGS="-g" sh makegap.sh 0x gapdummy.o
ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o ${OBJS}
textdatabss dec hex
11815507267748  1101824 13185079c93037
mv newbsd newbsd.gdb
ctfstrip -S -o newbsd newbsd.gdb
rm -f bsd.gdb
mv -f newbsd bsd
install -F -m 700 bsd /bsd && sha256 -h /var/db/kernel.SHA256 /bsd

Kernel has been relinked and is active on next reboot.

SHA256 (/bsd) = a940ce989d708e5b87a1186ee81bd624066baeabe67b8405b52e4fa2988b565


# dislabel -pm wd0
#size   offset  fstype [fsize bsize   cpg]
  a:   353.0M   64  4.2BSD   2048 16384  5624 # /
  b:   511.1M   722944swap# none
  c: 15280.0M0  unused
  d:   444.8M  1769728  4.2BSD   2048 16384  7116 # /tmp
  e:   607.7M  2680576  4.2BSD   2048 16384  9685 # /var
  f:  1703.0M  3925216  4.2BSD   2048 16384 12958 # /usr
  g:   505.8M  7412896  4.2BSD   2048 16384  8060 # /usr/X11R6
  h:  1632.9M  8448736  4.2BSD   2048 16384 12958 # /usr/local
  i:  1381.2M 11792960  4.2BSD   2048 16384 12958 # /usr/src
  j:  5282.4M 14621632  4.2BSD   2048 16384 12958 # /usr/obj
  k:  2850.9M 25439936  4.2BSD   2048 16384 12958 # /home



Re: bridge, vether & dhcpd

2020-03-17 Thread Stefan Sperling
On Tue, Mar 17, 2020 at 12:14:21PM +0100, Salvatore Cuzzilla wrote:
> nope, the L2 if(s) (including bridge) are running only with option ‘up’ 
> within hostname.if files
> & all the other L3 ifs are with IP statically assigned 

Then you need to share a lot more details, such as your pf.conf,
and tcpdumps from all relevant interfaces including pflog0 which
show the facts about the actual vs. expected flow of packets.



Re: bridge, vether & dhcpd

2020-03-17 Thread Stefan Sperling
On Tue, Mar 17, 2020 at 08:24:34AM +0100, Salvatore Cuzzilla wrote:
> Dear all,
> 
> is someone using a setup with multiple layer 2 interfaces & a single vether 
> IP interface (layer 3) bundled all together in a bridge?
> Well, i’m using this setup too and almost everything is working like 
> expected. 
> 
> However, 
> I have a couple of hosts  connected to the L2 interfaces & i would like them 
> to dynamically get an IP (dhcpd instance already up & running)
> atm, this is not working. I thought about PF , but probably it’s not the 
> issue …
> 
> any advice? configuration examples i can go through?
> 
> 

Is dhclient also running? If so, try to stop dhclient and see if
it works then.



Re: bwfm NVRAM file

2020-03-13 Thread Stefan Sperling
On Fri, Mar 13, 2020 at 12:12:18PM +0100, Rob Schmersel wrote:
> Question: Are there plans to include the NVRAM files in bwfm_firmware
> package?

Yes, this is being worked on. See these recent commits by Patrick:
https://marc.info/?l=openbsd-cvs=158357502421524=2
https://marc.info/?l=openbsd-cvs=158348413626641=2
https://marc.info/?l=openbsd-cvs=158348535827039=2

I am not involved but it sounds like this issue could be resolved
in time for the next release. But please have patience.



Re: Purging a wifi connection

2020-02-22 Thread Stefan Sperling
On Fri, Feb 21, 2020 at 07:40:23PM -0700, Raymond, David wrote:
> Thanks, I will give that a try.

Also 'ifconfig nwid' still works and will override any join commands.

Details are in the ifconfig man page. This page has received improvements
in -current recently. If you don't run a -current system please check the
online -current man page and compare it with the man page you see on a
6.6 system: https://man.openbsd.org/ifconfig
Most of what this -current page is saying applies to 6.6 as well.
A major behavioral difference between 6.6 and -current is that an interface
will no longer connect to random open wifi networks by default.



Re: ahci issue corebooted X220 does not recognise usb or stata

2020-02-21 Thread Stefan Sperling
You should be reporting these to coreboot, not here.

On Wed, Feb 19, 2020 at 02:34:40PM +0100, Thomas Meulendijks wrote:
> Hi OpenBSD Mailing list,
> 
> I am trying to install Openbsd via the install66.fs on a Thinkpad X220 
> [amd64] with coreboot.
> I have the problem that it does not recognize any USB or SATA device may it 
> be storage or peripherals like a keyboard, except for the boot USB.
> I tried with external USB storage, multiple different internal SSD's, 
> multiple USB keyboards, but sysctl does not show anything and dmesg does not 
> give a message when plugged in or out.
> I also tried with the grub and seabios payloads but it did not make a 
> difference.
> Coreboot and payloads are compiled at master and agenst the latest stable 
> version but it did not make a difference.
> coreboot Master version is 4.11-1189.
> 
> When I look at dmesg I see ahci failed, I know you guys will need to see my 
> dmesg but since I can't save it to a drive [read problem above]
> and the installation fs only has ftp to communicate to the web as far as I 
> can see and I don't know how to set up a ftp server, I am at a loss of how to 
> get it out.
> Maybe I am missing something?
> 
> A part of dmesg I think may be helpful that I typed over:
> 
> 
> em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x05: msiem0: The EEPROM 
> Checksum Is Not Valid
> em0: Unable to initialize the hardware
> ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apci 2 int 19
> ehci0: reset timeout
> ehci0 init failed, error=13
> 
> ehci1 at pci0 dev 29 function 0 "Intel 6 Series USB" rev 0x05: apci 2 int 18
> ehci1: reset timeout
> ehci1 init failed, error=13
> "Intel QM67 LPC" rev 0x05 at pci0 dev 31 function 0 not configured
> ahci0 at pci0 dev 31 function 2 "Intel 6 Series AHCI" rev 0x05: msi, unable 
> to reset controller
> "Intel 6 Series SMBus" rev 0x05 at pci0 dev 31 function 3 not configured
> "Intel 6 Series Thermal" rev 0x05 at pci0 dev 31 function 6 not configured
> 
> 
> I hope this is enough info and would greatly appreciate it if anyone could 
> help me out!
> 
> Greetings,
> 
> Thomas
> 
> 



Re: USB printer?

2020-02-18 Thread Stefan Sperling
On Mon, Feb 17, 2020 at 06:47:49PM +0100, Claus Assmann wrote:
> I got a 
> HP DeskJet 2630
> printer and connected it via usb
> I tried to use it "directly", i.e., /etc/printcap:
> usb:lp=/dev/ulpt0:sd=/var/spool/output/usb:sf:sh:tr=^D:
> as mentioned in the original mail
> 
> but this results in an "output error" after I started lpd
> and used
> lpr doc.ps
> 
>  ulpt0 at uhub0 port 4 configuration 1 interface 1 "HP DeskJet 2600 series" 
> rev 2.00/1.00 addr 2
>  ulpt0: using bi-directional mode
>  ugen0 at uhub0 port 4 configuration 1 "HP DeskJet 2600 series" rev 2.00/1.00 
> addr 2
>  ulpt0: output error
> 
> I didn't try to set up cups or similar stuff as that seems
> to be overkill for my simple use case and probably results
> in the same USB error?
> If someone has this kind of printer connected via USB: I am
> interested in the config.

Try the cups-filters package and follow the instructions given in
the file /usr/local/share/doc/pkg-readmes/cups-filters

You can't avoid the printer drivers from cups but you may be able to
get away with running lpd(8) instead of cupsd.
You will also need a2ps and a suitable printer driver (foo2zjs in my case).

Here are the packages I use for my HP LaserJet 1020:
a2ps-4.14p15format files for printing on PostScript printers
cups-filters-1.25.6 OpenPrinting CUPS filters
foo2zjs-20190909driver for ZjStream wire protocol compatible printers

Note however that ulpt(4) recognizes my printer and loads firmware for it.
If firmware is also required for your model to work (I have no idea if it is)
then the ulpt driver would need to be modified to do that, too.

$ cat /etc/printcap
lp|local line printer|HP-LaserJet_1020:\
:lf=/var/log/lpd-errs:\
:sd=/var/spool/output/lpd:\
:lp=/dev/ulpt0:\
:if=/etc/foomatic/direct/filter.sh:\ 
:sh:\
:mx#0:

And the filter script is this:

$ cat /etc/foomatic/direct/filter.sh
#!/bin/sh

# for debugging:
#echo "$*" >> /tmp/filter-args

args=`getopt cw:l:i:j:n:h: $*`
if [ $? -ne 0 ]
then
echo 'Usage: [-c] -wwidth -llength -iindent -n login -h host acct-file'
exit 2
fi

set -- $args

while [ $# -ne 0 ]
do
   case "$1"
   in
   -c)
   flag="$1"; shift;;
   -o|-w|-l|-i|-j|-n|-h)
   oarg="$2"; shift; shift;;
   --)
   shift; break;;
   esac
done

/usr/local/bin/a2ps -BRq --columns=1 -o - | \
/usr/local/bin/foomatic-rip -P HP-LaserJet_1020 \
--ppd /etc/foomatic/direct/HP-LaserJet_1020.ppd



Re: experience setting up a low memory machine

2020-02-15 Thread Stefan Sperling
On Sat, Feb 15, 2020 at 01:54:56AM +0100, Noth wrote:
> The only thing I can recommend is to stick to an older version of the OS

I wouldn't recommend running old releases, at least not until i386
officially becomes an unsupported platform.



Re: experience setting up a low memory machine

2020-02-15 Thread Stefan Sperling
On Fri, Feb 14, 2020 at 10:01:06PM +0900, rgc wrote:
> every boot OpenBSD relinks the kernel ... i stared at the top display and
> saw ld on top with around 170Mb ... literally out of memory ... and out of
> swap space. on machines with small memory swap is configured by disklabel
> as 2x physmem.  in my case 122Mb swap was calculated but it was not enough
> for the kernel relinking.

On an alix board with 256MB of RAM + 2G swap it is holding up OK.

With low-spec machines like this you need to add lots of swap or you will
need to get a bit creative. You can't use out of the box defaults on this
machine in any case, so some tweaking is required anyway.

For library relinking there's an rc.conf.local option to turn it off.

You can disable automatic kernel relinking, there is one obvious line
to remove from /etc/rc. You can still relink the kernel occasionally if
you want the added security.
Secret tip: You can compile an i386 kernel on a fast amd64 machine which
will also "relink" the kernel of course, just go into sys/arch/i386 and
do the usual kernel compile steps. Don't tell anyone I told you that!

If you want to go further and have another faster i386 machine you can follow
the release(8) man page to build custom release sets for your i386 laptop with
all the tweaks it needs included.



Re: Support for ath10k QCA988x devices

2020-02-01 Thread Stefan Sperling
On Tue, Jan 28, 2020 at 03:33:00PM -0800, Alexander Merritt wrote:
> On 2017-04-12 Stefan Sperling wrote
> > ath10k devices are not supported. They need a new driver because Atheros
> > has changed the driver<->hardware interface with this generation of devices.
> 
> Is there any update? A brief look in the source code and manual did not show 
> anything.

No. I have been too busy with Intel drivers instead.
Currently I am working on a new driver based on iwm(4) for newer
Intel hardware (ax200).
I don't want to work on more than one driver at a time.

It would be great if the industry stopped putting out new chipsets
for a few years so we can manage to catch up.

> What effort is required to implement a new driver, as Stefan mentions? Port 
> something from another BSD? From Linux? Start from scratch?

In this case it can be ported from Linux. However, that is a lot more
involved than mere copy/paste; it essentially requires going through
the entire driver and port the neccessary parts of the code incrementally.
Check Patrick's talk from EuroBSDcon 2019 about bwfm; this is a similar
situation.

> My motivation is to build a wireless router supporting 802.11ac (with OpenBSD 
> if possible). Compex WLE600VX and WLE900VX support 867Mbps and 1300Mbps, 
> respectively, according to their data sheets.
> 
> I am not bound to this chipset, if there are alternatives which do work.

The 11n support net80211 and iwm/iwn needs to be completed before
working on 11ac makes any sense. What is lacking in particular on
the way towards 11ac is 40 MHz channel support. Also, Tx aggregation
support needs to be added to iwm(4), as was done in iwn(4) some time ago.



Re: Question about "Game of Trees"

2020-01-14 Thread Stefan Sperling
On Mon, Jan 13, 2020 at 05:37:55PM -0700, Raymond, David wrote:
> Quick question: Can got (Game of Trees) be used on an existing git
> repository or does it require a fresh start?
> 
> Dave

Commands which only display repository data work out of the box on
any Git repository. This includes 'got log', 'got tree', and 'tog'.

To make changes with Got you can check out a work tree from any
existing Git repository. Given a Git repository in ~/src/myproject/
you would run something like this:

  got checkout ~/src/myproject src/myproject-got-work-tree
  cd ~/src/myproject-got-work-tree

>From this work tree you can commit changes with Got. Any changes you
commit will show up in the Git repository. Git's work tree will show
such changes as staged changes, and getting Git back on track requires
a command such as 'git reset --hard master'.

Got ignores Git's work tree and treats every Git repository as if it was
a so-called "bare" repository (a repository without a Git work tree).
See 'man git-repository' and 'man got-worktree' for details.



Re: Awaiting a diff [was: Re: File systems...]

2020-01-10 Thread Stefan Sperling
On Fri, Jan 10, 2020 at 12:52:44PM +0300, Consus wrote:
> On 20:06 Thu 09 Jan, Marc Espie wrote:
> > It's been that way for ages. But no-one volunteered
> > to work on this.
> 
> Anyone even knows about this? Aside from OpenBSD developers (who have
> their plates full already) how an average person can find out that there
> is rusty piece of code that should be taken care of?

Don't start looking at other people's problems before you can help yourself.
Rewriting automounter for Theo as a first contribution is not likely to work.
Find something small that annoys *you* and get involved by fixing that first.
Learn how to approach and debug issues that affect you directly.

How did I get into OpenBSD wifi?
Because my OpenBSD access point stopped accepting new associations after
one about week of usage. It turned out this was one of those problems
which had been known for years and all this time people had been switching
to non-OpenBSD APs to work around it. I had lived with the problem for
about a year or two, resetting the wifi interface on the AP whenever it
happened.

Then I noticed that 'ifconfig ath0 scan' showed a very long list of known
MAC addresses whenever the problem occurred. So I looked for a way trigger
the problem faster than in one week and succeeded by running this loop
on the client which made the problem appear after a few minutes:

  ifconfig iwn0 up
  while sleep 5; do ifconfig iwn0 lladdr random; done

Looking at the code I found that known MACs never expired! Once the AP had
reached its limit of learned MACs it accepted no new associations because
no room was made for new MAC addresses. Fix was a 3-line diff, which I
could verify with my above test.

---
commit 6bbde753957f0b27c56cfdd15c9af836579d120b
from: stsp 
date: Wed Jan 18 14:35:34 2012 UTC
 
 Make it possible to free cached nodes which never associated (e.g. nodes
 only scanning for networks). These were never put into COLLECT state and
 were thus never evicted from the node cache in hostap mode.
 ok jsg@
 
diff ae44467745d21c295e8ffe38340d662269578502 
d62cb122bc6abf011c13400ea5c3f90c56292854
blob - 893de460bfd2a1509205c4e5d837ba6f8d5c2636
blob + 9435a287862a29a9dc79ea09ce8328b8e054c819
--- sys/net80211/ieee80211_node.c
+++ sys/net80211/ieee80211_node.c
@@ -1507,8 +1507,10 @@ ieee80211_node_leave(struct ieee80211com *ic, struct i
 * If node wasn't previously associated all we need to do is
 * reclaim the reference.
 */
-   if (ni->ni_associd == 0)
+   if (ni->ni_associd == 0) {
+   ieee80211_node_newstate(ni, IEEE80211_STA_COLLECT);
return;
+   }
 
if (ni->ni_pwrsave == IEEE80211_PS_DOZE)
ic->ic_pssta--;



Re: Awaiting a diff [was: Re: File systems...]

2020-01-09 Thread Stefan Sperling
On Thu, Jan 09, 2020 at 12:47:31PM +0300, Consus wrote:
> Relax, it was a joke.

Whatever, what I wrote wasn't just directed at you.

misc@ sucks a lot lately.



Re: Awaiting a diff [was: Re: File systems...]

2020-01-09 Thread Stefan Sperling
On Thu, Jan 09, 2020 at 11:02:17AM +0300, Consus wrote:
> On 18:15 Wed 08 Jan, Xiyue Deng wrote:
> > It would be better to point out where to start, what hard problems to
> > solve, what work has been done in this area that people can continue
> > to work on.
> 
> They don't remember as there is no bugtracker.

When people report actual bugs, they get fixed so fast that tracking
them over days or weeks would be pointless.

"""
We thank Theo de Raadt and the OpenBSD developers for their incredibly
quick response: they published patches for these vulnerabilities less
than 40 hours after our initial contact. 
""" -- Qualys

Any non-critical stuff which gets reported ("my printer/wifi/usb doesn't work",
"kernel does not boot on my new laptop", "my system works but is slow") just
lands in an endless pile of problems that someone might eventually decide to
work on if they run into it again. Such issues happen over and over again,
all the time. Any developer picking them up ASAP over and over would burn out,
just like they do in companies with issue-tracker driven workflows. That's why
people demanding loudly to get such issues fixed are told to shut up.

And keep in mind that at any given moment there are only about 50 to 100
people doing actual work here. The rest of the world is busy elsewhere or
slacking.



Re: But there is Fossil...

2020-01-07 Thread Stefan Sperling
On Tue, Jan 07, 2020 at 12:26:49PM +, Roderick wrote:
> 
> On Mon, 6 Jan 2020, Sean Kamath wrote:
>  
> > Having said that, I use whatever repo projects provide.  I’m not here to 
> > say VCS “A” is better than VCS “B”, just saying installing various 
> > VCS’s under OpenBSD is pretty damn simple.
> 
> It seems to be like the wars perl vs python, emacs vs vi, etc.
> 
> But no, there are differences: it is groupware, about workflow.
> The appropriate VCS may depend on the way people works, see
> for example:
> 
> https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki

There's a lot of fluff in there which doesn't apply to Got in any way.
It used to be patches vs. CVS, then SVN vs. X, and these days it is
usually Git vs. X. The actual reasons why people start writing VCS tools
and make certain design choices rarely show up in high-level comparisons
written with the benefit of hindsight.

It is important to note that Got is not Git and while I took inspiration
from several other VCS systems I don't see any reason to write up detailed
comparisons between Got and any other systems. Taking over users from other
systems is not a goal. Those users already have the tools they need.

I am writing this tool so I can use it to hack on OpenBSD for which I
have already used and considered many VCS over years, including fossil:

$ ls -l *.fossil
-rw-r--r--  1 stsp  users  -  368K Jan 31  2017 athn.fossil
-rw-r--r--  1 stsp  users  -  180K Jan 17  2014 avr32.fossil
-rw-r--r--  1 stsp  users  -  912K Dec 25  2017 bgscan.fossil
-rw-r--r--  1 stsp  users  -  348K Jul 18  2014 bwi.fossil
-rw-r--r--  1 stsp  users  - 86.0K Jul 31  2014 dolphin.fossil
-rw-r--r--  1 stsp  users  - 1005K Feb  7  2015 iwm.fossil
-rw-r--r--  1 stsp  users  -  908K Jun  4  2016 iwm8k.fossil
-rw-r--r--  1 stsp  users  -  736K Nov 12  2016 mira.fossil
-rw-r--r--  1 stsp  users  -  117K Aug 27  2013 omedma.fossil
-rw-r--r--  1 stsp  users  -  100K Oct 21  2013 omsdma.fossil
-rw-r--r--  1 stsp  users  - 97.0K Dec 16  2013 rsu.fossil
-rw-r--r--  1 stsp  users  -  228K May 18  2014 run.fossil
-rw-r--r--  1 stsp  users  -  207K Jun  5  2015 urtwn.fossil
$

> (GIT has the repository inside the checkout). 

This is not the case with Got.

By the way, thank you for trimming the list of recipients down to misc@,



Re: But there is Fossil...

2020-01-06 Thread Stefan Sperling
On Mon, Jan 06, 2020 at 06:28:48PM +, go...@disroot.org wrote:
> done reading that entire document, however, this is a topic about
> OpenBSD choosing Git over Fossil, but the actual problem is
> reimplementing Git (Game of Trees is a Git implementation just
> like OpenGit) and that's ridiculous, however, having read
> that PDF document I question: which of those problems are
> present in Fossil, not Git? in presence of those problems,
> why not wait for fix in Fossil instead of rushing to
> reimplement Git? I always see the point in two things:
> 1. using something existing
> 2. innovating something new
> 
> Game of Trees and OpenGit are not innovations, they are
> implementations of existing innovation, if you've seen my
> first message, I suggested option 1

Look, if you don't like something why don't you just ignore it?
Instead of wasting time by writing pointless messages which the
many people on this list now have to delete from their inbox?

The gameoftrees FAQ says:
""
We don't need to hear your opinion that our project is pointless because
Git is superior. Thank you!
""
The same applies to Fossil or whatever else anyone thinks is superior.

Why should I care about your opinion on what I should be working
on in my spare time? It looks like you're just trying to annoy me.



Re: But there is Fossil...

2020-01-04 Thread Stefan Sperling
On Sun, Jan 05, 2020 at 12:33:58AM +, go...@disroot.org wrote:
> January 5, 2020 2:24 AM, "Roderick"  wrote:
> 
> > On Sun, 5 Jan 2020, go...@disroot.org wrote:
> > 
> >> so I don't understand what's wrong with FreeBSD and OpenBSD.
> > 
> > I do not see a problem in CVS.
> 
> Sure, but I started this thread because of OpenBSD's plan
> to migrate to Git.

Stop posting please.



Re: Hardware for Access Point on OpenBSD

2020-01-03 Thread Stefan Sperling
On Thu, Jan 02, 2020 at 12:56:13PM -, Stuart Henderson wrote:
> On 2020-01-01, List  wrote:
> > Hi *, 
> > I am currently building a home router based upon OpenBSD. 
> > I therefore need some kind of WIFI Hardware. This piece of hardware
> > needs to be connected over usb. 
> > Do you have any suggestions or recommendations ? As far as I can see
> > it's pretty hard  to find an antenna which is connected  via USB an runs
> > on a supported chipset. It is  easy to get your hands on a
> > realtek-chipset driven device. But urtw(4) doesn't support  Host AP
> > mode. Only ones that do are: athn(4),  ral(4), ath(4). 
> > Finding those is hard. 
> >
> > Maybe you guys know things I couldn't find ? 
> 
> bwfm(4) also supports hostap on USB devices and probably has the
> least-worst performance of devices that will attach directly to
> OpenBSD rather than as a separate "hardware" AP.

bwfm(4) hostap mode has some issues still, e.g. you cannot actually
force the channel to use.

And I'm not sure whether USB devices actually support hostap.



Re: Hardware for Access Point on OpenBSD

2020-01-03 Thread Stefan Sperling
On Wed, Jan 01, 2020 at 08:54:46AM -0700, List wrote:
> Hi *, 
> I am currently building a home router based upon OpenBSD. 
> I therefore need some kind of WIFI Hardware. This piece of hardware
> needs to be connected over usb. 
> Do you have any suggestions or recommendations ? As far as I can see
> it's pretty hard  to find an antenna which is connected  via USB an runs
> on a supported chipset. It is  easy to get your hands on a
> realtek-chipset driven device. But urtw(4) doesn't support  Host AP
> mode. Only ones that do are: athn(4),  ral(4), ath(4). 
> Finding those is hard. 
> 
> Maybe you guys know things I couldn't find ? 
> 
> g, 
> Stephan

Searching the web for AR9271 might turn up a working athn(4) USB device.

A brand called "ALFA networks" made devices that are plugged via a
mini-USB cable to you can place them far from your router. They also
have detachable antennas. Model no. AWUS036HNA.

That said, it's 2GHz only, and the firmware currently limits the number
of concurrent clients to 8 (apparently this limitation could be fixed).

Last I checked the USB stack still had stability issues with these devices.
Putting a self-powered USB hub between the device and your router could help.

Still, on USB, this is the best you could get.



Re: OpenBSD and ext2fs (ext3)

2019-12-27 Thread Stefan Sperling
On Fri, Dec 27, 2019 at 03:56:00PM +0100, Thomas de Grivel wrote:
> Hello,
> 
> I have a few ext3 drives from an old gentoo which mount fine but do
> not fsck (something about the first alternate superblock not matching
> values) they mount and fsck fine under linux.

OpenBSD ext3 support is limited and read-only. I wouldn't expect fsck
to work since fixing errors requires writing to the filesystem.
 
> The only exception being a 4Tb drive which panics when mounting the
> ext3 partition.
> 
> Is this expected or should I investigate further ?

Yes. Panics are not expected, though not unheard of with corrupt
filesystems or not well-tested filesystem code.



Re: Fun play with egrep, sed and awk

2019-12-26 Thread Stefan Sperling
On Thu, Dec 26, 2019 at 04:13:33PM +, goleo . wrote:
> Most of them are games, but what is Linux 4.20 kernel doing here?

sysutils/dtb



Re: installation question

2019-12-18 Thread Stefan Sperling
On Wed, Dec 18, 2019 at 05:05:26PM +0100, Mario Theodoridis wrote:
> Hi everyone,
> 
> this may sound silly but i'm trying to install 6.6 via serial console from
> install66.fs which is described as you know:
> 
> > A boot and installation image which contains
> > the base and X sets.  An install or upgrade can be
> > done with a USB key without network connectivity.
> 
> However when i get to the distribution sets my install looks like this:
> 
> > Let's install the sets!
> > Location of sets? (disk http nfs or 'done') [http] disk
> > Is the disk partition already mounted? [yes]

Try answering 'no' here and then selecting the 'a' partition
of the disk which contains install66.fs for mounting.



Re: cvs checkout of src,ports and xenocara gives duplicate key msg

2019-12-16 Thread Stefan Sperling
On Mon, Dec 16, 2019 at 10:55:17AM +0530, putridsou...@gmail.com wrote:
> Currently I'm running the -stable OPENBSD-6.6
> I want to set up the ports repository so 
> I followed the faqs to set up a /usr/ports partition,
> changed the group to wsrc and file modes to 775.
> Then I added my local user to wsrc group.
> After changing directory to /usr, I hit the following
> command
> 
> cvs -qd anon...@anoncvs.ca.openbsd.org:/cvs checkout  \
>  -rOPENBSD_6_6 -P ports
> 
> The output;
> cvs server: duplicate key found for 'y'
> U ports/.cvsignore
> U ports/Makefile
> ..and then the normal output followed.


Based on cvs code inspection it looks like the CVSROOT/val-tags
file is broken on the server.

I can reproduce this with a reposync'd CVS repository, too.
The last line in that file looks suspect. It contains no tag name:

$ tail CVSROOT/val-tags  
mesa-19_0_5 y
mesa-19_0_8 y
LLVM_8_0_0 y
LLVM_8_0_1 y
UNBOUND_1_9_3 y
OPENBSD_6_6 y
OPENBSD_6_6_BASE y
libdrm_2_4_100 y
kn y
 y
$ 



Re: urtwn(4) gets wedged periodically

2019-11-16 Thread Stefan Sperling
On Sat, Nov 16, 2019 at 05:24:37PM +0800, Kevin Lo wrote:
> Despite our USB issues, there are minor problems with the urtwn(4) for
> RTL8188C/RTL8192C:
> 
> - we don't need to enable/disable efuse access protection; it may prevent
>   incorrect mac address read from efuse.
> - disable BB/RF is not needed.

ok stsp@

> Index: sys/dev/ic/rtwn.c
> ===
> RCS file: /cvs/src/sys/dev/ic/rtwn.c,v
> retrieving revision 1.46
> diff -u -p -u -p -r1.46 rtwn.c
> --- sys/dev/ic/rtwn.c 25 Apr 2019 01:52:13 -  1.46
> +++ sys/dev/ic/rtwn.c 16 Nov 2019 09:23:07 -
> @@ -529,7 +529,9 @@ rtwn_efuse_read(struct rtwn_softc *sc, u
>   uint32_t reg;
>   int i, len;
>  
> - rtwn_write_1(sc, R92C_EFUSE_ACCESS, R92C_EFUSE_ACCESS_ON);
> + if (!(sc->chip & (RTWN_CHIP_92C | RTWN_CHIP_88C)))
> + rtwn_write_1(sc, R92C_EFUSE_ACCESS, R92C_EFUSE_ACCESS_ON);
> +
>   rtwn_efuse_switch_power(sc);
>  
>   memset(rom, 0xff, size);
> @@ -571,7 +573,8 @@ rtwn_efuse_read(struct rtwn_softc *sc, u
>   printf("\n");
>   }
>  #endif
> - rtwn_write_1(sc, R92C_EFUSE_ACCESS, R92C_EFUSE_ACCESS_OFF);
> + if (!(sc->chip & (RTWN_CHIP_92C | RTWN_CHIP_88C)))
> + rtwn_write_1(sc, R92C_EFUSE_ACCESS, R92C_EFUSE_ACCESS_OFF);
>  }
>  
>  void
> Index: sys/dev/usb/if_urtwn.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
> retrieving revision 1.84
> diff -u -p -u -p -r1.84 if_urtwn.c
> --- sys/dev/usb/if_urtwn.c12 Sep 2019 12:55:07 -  1.84
> +++ sys/dev/usb/if_urtwn.c16 Nov 2019 09:23:07 -
> @@ -1704,21 +1704,6 @@ urtwn_r92c_power_on(struct urtwn_softc *
>   urtwn_write_2(sc, R92C_SYS_ISO_CTRL,
>   urtwn_read_2(sc, R92C_SYS_ISO_CTRL) & ~R92C_SYS_ISO_CTRL_DIOR);
>  
> - /* Initialize MAC. */
> - urtwn_write_1(sc, R92C_APSD_CTRL,
> - urtwn_read_1(sc, R92C_APSD_CTRL) & ~R92C_APSD_CTRL_OFF);
> - for (ntries = 0; ntries < 200; ntries++) {
> - if (!(urtwn_read_1(sc, R92C_APSD_CTRL) &
> - R92C_APSD_CTRL_OFF_STATUS))
> - break;
> - DELAY(5);
> - }
> - if (ntries == 200) {
> - printf("%s: timeout waiting for MAC initialization\n",
> - sc->sc_dev.dv_xname);
> - return (ETIMEDOUT);
> - }
> -
>   /* Enable MAC DMA/WMAC/SCHEDULE/SEC blocks. */
>   reg = urtwn_read_2(sc, R92C_CR);
>   reg |= R92C_CR_HCI_TXDMA_EN | R92C_CR_HCI_RXDMA_EN |
> 
> 



Re: urtwn(4) gets wedged periodically

2019-11-14 Thread Stefan Sperling
On Wed, Nov 13, 2019 at 12:30:23PM -0700, Theo de Raadt wrote:
> These are usb devices.  There are multiple usb bus drivers, with
> usb2 and usb3 variations, and the usb subsystem itself.  The mailing
> lists are full of discussions of bugs in usb.
> 
> But no, let's keep concluding these problems is narrowly restricted
> to a specific brand of device...

I have given up on trying to figure out non-obvious bugs in USB wifi
drivers for this reason. We need someone to look into USB issues in
order to make progress on the various hangs and power consumption
problems people have been reporting against drivers such as urtwn(4).

Granted, there could always be a bug in the wifi driver, but not having
reliable USB drivers beneath does not exactly help with debugging.

xhci(4) has problems on certain host controller models for instance.
We don't even have all the quirks and workarounds which other operating
systems apply to various host controller chipsets in our xhci(4) driver.
And then there are bugs specific to our implementation, such as this one
which was recently discovered by gerhard@:
https://marc.info/?l=openbsd-tech=157355206323832=2
We need more research into this area of bugs but we don't currently have
people who do it.

I also believe that bus power management in xhci(4) and ehci(4) is broken.
I cannot prove it, but it would be great if somebody looked into this to
find answers. athn(4) on USB seems to be suffering from something like this.



Re: Skype alternatives for OpenBSD

2019-11-03 Thread Stefan Sperling
On Sat, Nov 02, 2019 at 02:47:16PM -0700, Jordan Geoghegan wrote:
> Assuming Firefox or chromium on OpenBSD has WebRTC support (havent checked
> in a while), talky.io should work. It's a free website that supports WebRTC
> chats. I've used it in the past with great success.

The www/nextcloud port with the 'Talk' add-on, and with telephony/turnserver,
can be used to self-host a WebRTC server on OpenBSD.



Re: Broadcom firmwares and nvram files

2019-11-03 Thread Stefan Sperling
On Sun, Nov 03, 2019 at 10:06:18AM +0100, Patrick Wildt wrote:
> Obiously I missed the attachment.

Could this tool be put into base or ports / pkg_add?

> /*
>  * Copyright (c) 2013 Broadcom Corporation
>  *
>  * Permission to use, copy, modify, and/or distribute this software for any
>  * purpose with or without fee is hereby granted, provided that the above
>  * copyright notice and this permission notice appear in all copies.
>  *
>  * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
>  * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
>  * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
>  * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
>  * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN 
> ACTION
>  * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
>  * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>  */
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> //#include 
> 
> #define BRCMF_FW_MAX_NVRAM_SIZE   64000
> #define BRCMF_FW_NVRAM_DEVPATH_LEN19  /* devpath0=pcie/1/4/ */
> #define BRCMF_FW_NVRAM_PCIEDEV_LEN10  /* pcie/1/4/ + \0 */
> #define BRCMF_FW_DEFAULT_BOARDREV "boardrev=0xff"
> 
> enum nvram_parser_state {
>   IDLE,
>   KEY,
>   VALUE,
>   COMMENT,
>   END
> };
> 
> /**
>  * struct nvram_parser - internal info for parser.
>  *
>  * @state: current parser state.
>  * @data: input buffer being parsed.
>  * @nvram: output buffer with parse result.
>  * @nvram_len: lenght of parse result.
>  * @line: current line.
>  * @column: current column in line.
>  * @pos: byte offset in input buffer.
>  * @entry: start position of key,value entry.
>  * @multi_dev_v1: detect pcie multi device v1 (compressed).
>  * @multi_dev_v2: detect pcie multi device v2.
>  * @boardrev_found: nvram contains boardrev information.
>  */
> struct nvram_parser {
>   enum nvram_parser_state state;
>   char *data;
>   char *nvram;
>   uint32_t nvram_len;
>   uint32_t line;
>   uint32_t column;
>   uint32_t pos;
>   uint32_t entry;
>   int multi_dev_v1;
>   int multi_dev_v2;
>   int boardrev_found;
> };
> 
> /**
>  * is_nvram_char() - check if char is a valid one for NVRAM entry
>  *
>  * It accepts all printable ASCII chars except for '#' which opens a comment.
>  * Please note that ' ' (space) while accepted is not a valid key name char.
>  */
> static int is_nvram_char(char c)
> {
>   /* comment marker excluded */
>   if (c == '#')
>   return 0;
> 
>   /* key and value may have any other readable character */
>   return (c >= 0x20 && c < 0x7f);
> }
> 
> static int is_whitespace(char c)
> {
>   return (c == ' ' || c == '\r' || c == '\n' || c == '\t');
> }
> 
> static enum nvram_parser_state brcmf_nvram_handle_idle(struct nvram_parser 
> *nvp)
> {
>   char c;
> 
>   c = nvp->data[nvp->pos];
>   if (c == '\n')
>   return COMMENT;
>   if (is_whitespace(c) || c == '\0')
>   goto proceed;
>   if (c == '#')
>   return COMMENT;
>   if (is_nvram_char(c)) {
>   nvp->entry = nvp->pos;
>   return KEY;
>   }
>   printf("warning: ln=%d:col=%d: ignoring invalid character\n",
> nvp->line, nvp->column);
> proceed:
>   nvp->column++;
>   nvp->pos++;
>   return IDLE;
> }
> 
> static enum nvram_parser_state brcmf_nvram_handle_key(struct nvram_parser 
> *nvp)
> {
>   enum nvram_parser_state st = nvp->state;
>   char c;
> 
>   c = nvp->data[nvp->pos];
>   if (c == '=') {
>   /* ignore RAW1 by treating as comment */
>   if (strncmp(>data[nvp->entry], "RAW1", 4) == 0)
>   st = COMMENT;
>   else
>   st = VALUE;
>   if (strncmp(>data[nvp->entry], "devpath", 7) == 0)
>   nvp->multi_dev_v1 = 1;
>   if (strncmp(>data[nvp->entry], "pcie/", 5) == 0)
>   nvp->multi_dev_v2 = 1;
>   if (strncmp(>data[nvp->entry], "boardrev", 8) == 0)
>   nvp->boardrev_found = 1;
>   } else if (!is_nvram_char(c) || c == ' ') {
>   printf("warning: ln=%d:col=%d: '=' expected, skip invalid key 
> entry\n",
> nvp->line, nvp->column);
>   return COMMENT;
>   }
> 
>   nvp->column++;
>   nvp->pos++;
>   return st;
> }
> 
> static enum nvram_parser_state
> brcmf_nvram_handle_value(struct nvram_parser *nvp)
> {
>   char c;
>   char *skv;
>   char *ekv;
>   uint32_t cplen;
> 
>   c = nvp->data[nvp->pos];
>   if (!is_nvram_char(c)) {
>   /* key,value pair complete */
>   ekv = >data[nvp->pos];
>   skv = 

Re: Display flickers after upgrade to 6.6

2019-10-19 Thread Stefan Sperling


On Sat, Oct 19, 2019 at 04:17:15PM +0200, Andre Stoebe wrote:
> Hi,
> 
> I ran into the same issue this morning. Disabling the compositor worked
> for me, but I noticed later that this is also documented in the package
> readme:

Thanks! Trying that now.
 
> Screen compositor
> =
> If you're using the modesetting X driver and experience window
> flickering when
> the compositor is enabled, you should force the window manager to use the
> XPresent method for vblank:
> 
> $xfwm4 --vblank=xpresent --replace &
> 
> This is documented upstream at
> https://git.xfce.org/xfce/xfwm4/tree/COMPOSITOR#n114
> 
> Haven't tested that yet and left the compositor disabled, but I guess
> this will fix your issues. If it does, that's probably a good reminder
> to first look in the readme next time (me included). ;)
> 
> Regards,
> André
> 
> 



Re: Display flickers after upgrade to 6.6

2019-10-19 Thread Stefan Sperling
On Sat, Oct 19, 2019 at 03:18:53PM +0200, Stefan Sperling wrote:
> On Sat, Oct 19, 2019 at 01:44:32PM +0200, Federico Giannici wrote:
> > Today I switched my desktop PC, with Xfce, to OpenBSD amd64 6.6.
> > 
> > Since the upgrade the display started to flickers. It seems to me that the
> > desktop background flashes over the various windows.
> > 
> > I vaguely remember that i read something about this problem in a message in
> > these mailings a couple months ago, with someone suggesting a solution. I
> > searched these mailing archives but I wasn't able to find that message.
> > 
> > Someone can direct me to the suggested solution?
> > 
> > Thanks.
> > 
> > P.S.
> > Here is the dmesg:
> 
> I am also seeing this.
> It could be related to radeondrm since we are both using it.

Something else which could be relevant is that xfce now ships its
own screensaver. This screensaver shows the desktop background by default.

I already tried disabling it in settings but the xfce4-screensaver process
remains active even when the screensaver is disabled.



Re: Display flickers after upgrade to 6.6

2019-10-19 Thread Stefan Sperling
On Sat, Oct 19, 2019 at 01:44:32PM +0200, Federico Giannici wrote:
> Today I switched my desktop PC, with Xfce, to OpenBSD amd64 6.6.
> 
> Since the upgrade the display started to flickers. It seems to me that the
> desktop background flashes over the various windows.
> 
> I vaguely remember that i read something about this problem in a message in
> these mailings a couple months ago, with someone suggesting a solution. I
> searched these mailing archives but I wasn't able to find that message.
> 
> Someone can direct me to the suggested solution?
> 
> Thanks.
> 
> P.S.
> Here is the dmesg:

I am also seeing this.
It could be related to radeondrm since we are both using it.

OpenBSD 6.6 (GENERIC.MP) #372: Sat Oct 12 10:56:27 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4008247296 (3822MB)
avail mem = 3874066432 (3694MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f800 (50 entries)
bios0: vendor American Megatrends Inc. version "V2.4" date 12/09/2009
bios0: MICRO-STAR INTERNATIONAL CO.,LTD MS-7596
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) 
PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) P0PC(S4) UHC1(S4) UHC2(S4) 
UHC3(S4) USB4(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Phenom(tm) II X4 945 Processor, 3000.51 MHz, 10-04-03
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache, 6MB 64b/line 48-way L3 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu0: AMD erratum 721 detected and fixed
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Phenom(tm) II X4 945 Processor, 3000.16 MHz, 10-04-03
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache, 6MB 64b/line 48-way L3 cache
cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu1: AMD erratum 721 detected and fixed
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Phenom(tm) II X4 945 Processor, 3000.16 MHz, 10-04-03
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC
cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache, 6MB 64b/line 48-way L3 cache
cpu2: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu2: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu2: AMD erratum 721 detected and fixed
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD Phenom(tm) II X4 945 Processor, 3000.16 MHz, 10-04-03
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC
cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache, 6MB 64b/line 48-way L3 cache
cpu3: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu3: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu3: AMD erratum 721 detected and fixed
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P0P1)
acpiprt2 at acpi0: bus -1 (PCE2)
acpiprt3 at acpi0: bus -1 (PCE3)
acpiprt4 at acpi0: bus 2 (PCE4)
acpiprt5 at acpi0: bus 3 (PCE5)
acpiprt6 at acpi0: bus -1 (PCE6)
acpiprt7 at acpi0: bus -1 (PCE7)
acpiprt8 at acpi0: bus -1 (PCE9)
acpiprt9 at acpi0: bus -1 (PCEA)
acpiprt10 at acpi0: bus -1 

Re: Do OpenBSD developers approve Isotop?

2019-10-14 Thread Stefan Sperling
On Sun, Oct 13, 2019 at 10:31:55PM -0300, Clark Block wrote:
> Do OpenBSD developers approve Isotop?
> 
> If not, why OpenBSD developers don't approve Isotop?
> 
> Reference Isotop: https://3hg.fr/Isos/isotop/

OpenBSD code is free for anyone to use for any purpose. We don't stamp
a seal of approval onto anything anyone else does with the code.

Whether or not you want to make use of isotop is your own decision.

If you're asking whether OpenBSD developers would want to support people
who are running into problems with isotop, the answer will in general be
"No" because there is already enough work to do.



Re: NPPPD Server behind a firewall

2019-10-14 Thread Stefan Sperling
On Mon, Oct 14, 2019 at 05:55:58PM +1100, Damian McGuckin wrote:
> Because I had a working L2TP server setup on $L2TP, I was not going to
> go into its pf.conf, ipsec.conf, or anything else. But here is npppd.conf
> 
> ike passive esp transport \
> proto udp from egress to any port 1701 \
> main auth "hmac-sha1" enc "3des" group modp1024 \
> quick auth "hmac-sha1" enc "3des" group modp1024 \
> psk "MYSECRET"

As an aside, you should avoid use of 3des because it is effecively plaintext.
There are ways to make even Windows clients use actual crypto with IPsec if
needed, though last I checked it could not be done from the GUI but required
powershell commands. (I don't have a URL handy, sorry, but this information
wasn't very hard to find when I needed it.)
 
> Now I want to move the machine to a new site behind a new OpenBSD firewall,
> say FIRE. The difference is that now, $L2TP will have an unroutable address,
> say 10.200.100.200, or $L2TPI, as the IP on its external interface.  It will
> obviously have an external address, $L2TPX, but that will be exposed through
> FIRE, the external firewall. I want to binat from L2TPX->L2TPI.

> Any suggestions on what I have done wrong or what I need to do right.

You could try to pin-point the problem a bit more, starting with diagnostics
at the IPsec layer. Check debug logs from isakmpd, check ipsectl -sa, etc.
I suspect getting IPsec SAs going with both peers behind NAT is tricky.
I believe it should be possile in theory but I cannot confirm whether our
implementation can do this easily. It will certainly involve UDP traffic
since AH/ESP cannot pass through NAT.

If your IPsec SAs already work for other traffic, but npppd won't work,
that would imply that npppd has a limitation related to NAT; perhaps it
encodes the end-point IPs it is seeing in the L2TP protocol, which would
not match the actual layer 3 addresses used by IPsec?



Re: Status of ath10k?

2019-10-06 Thread Stefan Sperling
On Sun, Oct 06, 2019 at 12:31:13PM +0200, Gregor Best wrote:
> What's the status of that on OpenBSD? Is there a driver under way or is
> this a "get comfortable with a urtwn or hack it yourself" situation?

That's the current situation, yes.

If you want to hack on it yourself, talk to me and patrick@ so you
can start from 0.1% instead of 0%.



Re: Alix 2d13 and OpenBSD 6.5 Problems

2019-10-02 Thread Stefan Sperling
On Tue, Oct 01, 2019 at 10:46:50PM -0700, Sean Kamath wrote:
> Hi.
> 
> I’m hoping someone either has a cluebat or some helpful suggestions beyond 
> “reinstall”.

Try adding swap space.
I have added 2GB of swap space on my alix and it has been running fine ever 
since.

I avoided a reinstall by repurposing unused /usr/src and /usr/obj partitions.
Snippet from /etc/fstab:

#/dev/wd0i /usr/src ffs rw,nodev,nosuid,softdep 1 2
#/dev/wd0j /usr/obj ffs rw,nodev,nosuid,softdep 1 2
/dev/wd0i none swap sw 0 0
/dev/wd0j none swap sw 0 0



Re: Cannot add login class (ports/meta/gnome/pkg/README-main)

2019-09-17 Thread Stefan Sperling
On Tue, Sep 17, 2019 at 02:21:21PM +0100, Patrick Harper wrote:
> With this setup there is a functionality issue - logging out
> through the UI causes gdm to exit to the console (although the daemon seems
> to continue running), whereas it should display the gdm greeter. Whether or
> not this is a byproduct of the staff class settings I don't know.

Known problem. You will likely find a gdm.core or gnome-session-binary.core
file somewhere. It's a crash due to some bug in gdm/glib/gtk/etc.
Someone needs to debug and fix it.



Re: recent troubles with iwn(4)

2019-09-11 Thread Stefan Sperling
On Wed, Sep 11, 2019 at 08:01:25AM +, Bryan Stenson wrote:
> sorry about that...here's the most recent one:
> 
> Sep 11 06:31:13 e530c /bsd: iwn0: sending probe_req to
> 80:2a:a8:57:5e:17 on channel 6 mode 11n

> Sep 11 06:31:18 e530c /bsd: iwn0: RUN -> SCAN

This means it has stopped receiving beacons from your AP.

Did the AP decide to switch its channel?



Re: recent troubles with iwn(4)

2019-09-11 Thread Stefan Sperling
On Wed, Sep 11, 2019 at 12:16:06AM -0700, Bryan Stenson wrote:
> doh...I don't know why I didn't think of that...
> 
> Good news, with 'ifconfig iwn0 debug' set, once the strange behavior
> starts, I see LOTS of repeated messages, the pattern happens about
> once every 4 seconds, and dumps the following into /var/log/messages:
> 
> ...
> # continuous spamming of /var/log/messages from after the network has
> been in the troubled/failed state for a while

You snipped the exciting part.

I need to know why it decides to do a transition of the form:

RUN -> something

This should be somewhere at the top of this stream of output.



Re: athn bugs: usbd_free_xfer and fail HT-MCS

2019-09-10 Thread Stefan Sperling
On Mon, Sep 09, 2019 at 03:08:42PM -0300, soiahf...@airmail.cc wrote:
> New issue prompted today:
> 
> athn0: device time out
> athn0: firmware command 0x11 timed out
> athn0: could not remove station 1 (-address-) from table
> athn0: firmware command 0x14 timed out
> athn0: firmware command 0x15 timed out
> 
> I was unable to reconnect. Solved after physically removing the
> usb adapter and restarting the network (sh /etc/network), unlike
> the previous issue, which was only solved after rebooting the system.
> Sometimes the interface mode keeps changing between OFDM48 and OFDM58,
> even though I've forced the mode in hostname.athn0.
> 
> Please let me know how I can bring more useful informations (debug)
> to solve these issues i athn, hopefully before the new release.
> 

In cases where you have to reboot the system, I believe you are seeing
effects from bugs in our USB stack, related to management of available
power on the bus.

I don't have time or interest to dig into this, sorry. But this is an area
where we realy need some help. Several USB wifi drivers have had bugs filed
against them that look similar to this, and which tend to disappear when
using such devices on a different machine with a different USB chipset.



Re: recent troubles with iwn(4)

2019-09-09 Thread Stefan Sperling
On Mon, Sep 09, 2019 at 10:26:37AM +0100, Raf Czlonka wrote:
> Your email prompted me today to have a look at what is happening
> while the laptop loses connectivity - it's been disconnected for 3
> days after about 30 minutes of being connected (enough time to run
> 'pkg_add -u'). After putting the interface into debug modes:
> 
>   # ifconfig iwn0 debug
> 
> /var/log/messages shows:
> 
>   iwn0: AUTH -> SCAN
>   iwn0: end active scan
>   iwn0: - [...]
>   iwn0: - 12:34:56:12:34:56   11  +212 54M ess  privacy   rsn  "MYNWID2"!
>   iwn0: + 12:34:56:12:34:57   44  +203 54M ess  privacy   rsn  "MYNWID5"
>   iwn0: - [...]
>   iwn0: SCAN -> AUTH
>   iwn0: sending auth to 12:34:56:12:34:57 on channel 44 mode 11a

This small part of the log is not useful by itself, unfortunately.
You need to show debug output where iwn left RUN state in the first place. 

> What seems strange there is the mode - after a very brief look, it
> seems like the laptop is "stuck" trying to use 11a mode.
> 
> After forcing the 11n mode:
> 
>   # ifconfig iwn0 mode 11n
> 
> it connects instantaneously:

This command resets everything and the condition which triggered the
problem is now gone.

It connected fine to your 2 GHz AP. You have only shown failing connection
attempts to your 5 GHz AP. Did your 5 GHz AP ever actually work with iwn?



  1   2   3   4   5   6   7   8   9   >