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

[Stefan Sperling]

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

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

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

[Stefan Sperling]

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

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

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

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

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

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

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

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

[readme]

On Wed, Mar 16, 2022 at 10:11:50AM +0100, Stefan Sperling wrote:
>Looks like a firwmare or driver issue to me.
>
>Sorry, without having a reproducible test case in front of me, there
>is nothing I could do fix this from afar.

I mean, in fact it's 100% reproducible.

>You could try moving the AP to a different channel as a workaround.

I've already tried that and it doesn't solve the problem at all.

Thanks anyway. 

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

[Stefan Sperling]

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

Looks like a firwmare or driver issue to me.

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

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

[readme]

On Tue, Mar 15, 2022 at 05:19:34PM +0100, Stefan Sperling wrote:
>On Tue, Mar 15, 2022 at 09:09:57AM -0500, rea...@catastrophe.net wrote:
[..]
>> # ifconfig iwm0 mediaopt monitor mode 11n
>> # ifconfig iwm0 chan 132
>> # ifconfig iwm0 up
[..]
> 
>> Next I'll try join the network using the 5Ghz ssid on channel 132
>> 
>> # ifconfig iwm0 -mediaopt monitor
>
>Internally, the channel set for monitor mode is tracked in a different
>variable than in the other modes (yet another thing that should probably
>be fixed).
>
>So try clearing and setting the channel again at this point.

[..]

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

Ok, please see the following. The card is cleared of its monitor config then
put onto channel 132 in debug mode.

# ifconfig iwm0 -chan
# ifconfig iwm0 -mediaopt monitor
# ifconfig iwm0
iwm0: flags=8806 mtu 1500
lladdr 80:19:34:ab:ab:ab
index 5 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect mode 11n (HT-MCS0 mode 11n)
status: no network
ieee80211: nwid ""
# ifconfig iwm0 chan 132
# ifconfig iwm0 debug

# ifconfig iwm0
iwm0: flags=8847 mtu 1500
lladdr 80:19:34:ab:ab:ab
index 5 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect mode 11n (HT-MCS0 mode 11n)
status: no network
ieee80211: nwid "" chan 132

# date  
Mar 15 14:39:48 CDT 2022

# tail -f /var/log/messages
Mar 15 14:39:50 admiralty /bsd: iwm0: SCAN -> SCAN
Mar 15 14:39:54 admiralty /bsd: iwm0: end passive scan
Mar 15 14:39:54 admiralty /bsd: iwm0: - 04:d4:c4:XX:ab:24   44!  +12 54M   ess  
privacy!   no  "FOREIGN-NET-A"!
Mar 15 14:39:54 admiralty /bsd: iwm0: - 3c:28:6d:XX:6d:dc   11!  +14 54M   ess  
privacy!   no  "FOREIGN-NET-B"!
Mar 15 14:39:54 admiralty /bsd: iwm0: - 3c:7c:3f:XX:99:a86!  +12 54M   ess  
privacy!   no  "FOREIGN-NET-C"!
Mar 15 14:39:54 admiralty /bsd: iwm0: - 60:45:cb:XX:99:c09!  +22 54M   ess  
privacy!   no  "GJMD"!
Mar 15 14:39:54 admiralty /bsd: iwm0: - 60:45:cb:XX:99:c4  165!  +24 54M   ess  
privacy!   no  "GJMD_5G"!
Mar 15 14:39:54 admiralty /bsd: iwm0: - 6a:db:f5:XX:c9:2e  165!  +29 54M   ess  
privacy!   no  "DIRECT-As-FireTV_1353"!
Mar 15 14:39:54 admiralty /bsd: iwm0: - 6c:70:9f:AA:BB:CC1!  +11 54M   ess  
privacy!   no  "WIFI-NET"!
Mar 15 14:39:54 admiralty /bsd: iwm0: - 70:4f:57:XX:0d:b39!  +16 54M   ess  
privacy!   no  "Taffi"!
Mar 15 14:39:54 admiralty /bsd: iwm0: - fc:15:b4:XX:78:1f   11!  +25 54M   ess  
privacy!   no  "HP-Print-1F-ENVY 5530 series"!
Mar 15 14:39:54 admiralty /bsd: iwm0: SCAN -> SCAN

Only WIFI-NET still comes in the scan results on channel 1. While I do see
foreign networks on 5Ghz channels, nothing shows for the ssid WIFI-NET-5G

A linux machine connected to WIFI-NET-5G shows:

linux$ iwconfig wlan0
wlan0 IEEE 802.11  ESSID:"WIFI-NET-5G"
  Mode:Managed  Frequency:5.66 GHz  Access Point: 6C:70:9F:AA:BB:CD
  Bit Rate=195 Mb/s   Tx-Power=31 dBm   
  Retry short limit:7   RTS thr:off   Fragment thr:off
  Power Management:on
  Link Quality=41/70  Signal level=-69 dBm 
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:37  Invalid misc:0   Missed beacon:0

linux$ iwlist wlan0 channel | grep Current
  Current Frequency:5.66 GHz (Channel 132)

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

[Stefan Sperling]

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

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

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

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

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

Please enable: ifconfig iwm0 debug

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

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

[readme]

On Tue, Mar 15, 2022 at 02:15:41PM +0100, Stefan Sperling wrote:
>On Tue, Mar 15, 2022 at 08:02:07AM -0500, rea...@catastrophe.net wrote:
>> Unfortunately it appears as though I've run into it. Is there any recourse
>> to provide more useful debugging information to find the issue?
>
>I already gave you a workaround:
>
>ifconfig iwm0 mediaopt monitor mode 11n
>ifconfig iwm0 chan 132

Yes you did, and I greatly appreciate it. However, the interface won't
join to anything once out of monitor mode.

# uname -a
OpenBSD server.example.org 7.0 GENERIC.MP#5 amd64

# ifconfig iwm0 mediaopt monitor mode 11n
# ifconfig iwm0 chan 132
# ifconfig iwm0 up
# ifconfig iwm0
iwm0: flags=8843 mtu 1500
lladdr 80:19:34:ab:ab:ab
index 5 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect mode 11n monitor
status: active
ieee80211: nwid "" chan 132

# tcpdump -n -i iwm0 -y IEEE802_11_RADIO
tcpdump: listening on iwm0, link-type IEEE802_11_RADIO
08:49:46.490039 802.11: block ack, 
08:49:46.520556 802.11: block ack, 
08:50:18.285120 802.11: cts, 
08:50:18.285131 802.11: block ack, 
08:50:34.311166 802.11: probe request, 
08:50:34.321543 802.11: probe request, 
08:50:34.608507 802.11: block ack, 
08:50:39.877039 802.11: block ack, 
08:51:18.327816 802.11: block ack, 
08:51:34.567355 802.11: block ack, 
08:51:34.599644 802.11: block ack, 
08:51:39.836551 802.11: block ack, 
08:51:41.672562 802.11: probe request, 
08:51:46.525799 802.11: block ack, 
08:52:18.285393 802.11: block ack, 
08:52:18.357543 802.11: block ack, 
08:52:34.567315 802.11: block ack, 
08:52:34.806394 802.11: no-data: , 
08:52:39.836426 802.11: block ack, 

Next I'll try join the network using the 5Ghz ssid on channel 132

# ifconfig iwm0 -mediaopt monitor
# ifconfig iwm0 nwid WIFI-NET-5G wpakey skcuserawmrifletni
# ifconfig iwm0 192.168.1.8/24
# ifconfig iwm0
iwm0: flags=8843 mtu 1500
lladdr 80:19:34:ab:ab:ab
index 5 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect mode 11n (HT-MCS0 mode 11n)
status: no network
ieee80211: nwid WIFI-NET-5G chan 132 wpakey wpaprotos wpa2 wpaakms psk 
wpaciphers ccmp wpagroupcipher ccmp
inet 192.168.1.8 netmask 0xff00 broadcast 192.168.1.255

At this point, the interface never leaves status of "no network".

I also tried with another network near me (to rule out it being an Apple
Airport issue) and have the same issues.

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

[Stefan Sperling]

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

I already gave you a workaround:

ifconfig iwm0 mediaopt monitor mode 11n
ifconfig iwm0 chan 132

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

[readme]

On Mon, Mar 14, 2022 at 11:37:15PM +0100, Stefan Sperling wrote:
>On Mon, Mar 14, 2022 at 05:16:32PM -0500, rea...@catastrophe.net wrote:
>> Trying to manually monitor channel 132, I get an error, SIOCS80211CHANNEL.
>> 
[..]
>> # ifconfig iwm0 chan 132
>> ifconfig: SIOCS80211CHANNEL: Invalid argument
>
>The device should support this channel. This gives a list: ifconfig iwm0 chan

I see the channel, for sure.

$ ifconfig iwm0 chan | wc -l
  46
$ ifconfig iwm0 chan | grep 132
 132  5660 MHz  passive scan

[..]

>In the implementation, the mode determines which channels are available,
>not the other way around.
>And for some reason your interface goes into a mode that only supports
>2 GHz band channels.

>This should be fixed, when the user says "chan 132" ifconfig or the kernel
>should figure out that the mode needs to be switched if it is incompatible
>with the requested channel. It's one of those bugs that nobody ever runs
>into unless they are debugging things.

Unfortunately it appears as though I've run into it. Is there any recourse
to provide more useful debugging information to find the issue?

[..]

>> Even after a clean reboot I can't bring the interface up in monitor mode
>> and join anything other than channels 1-11.
>
>That is expected.
>You cannot use network in monitor mode at all, only listen to a channel.
>In order to join a network, you need to disable monitor mode again first:
>ifconfig iwm0 -mediaopt monitor -mode -chan

Good to know, thank you.

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

[Stefan Sperling]

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

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

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

ifconfig iwm0 mediaopt monitor mode 11n
ifconfig iwm0 chan 132

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

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

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

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

[readme]

On Mon, Mar 14, 2022 at 10:34:04PM +0100, Stefan Sperling wrote:
>On Mon, Mar 14, 2022 at 04:07:33PM -0500, rea...@catastrophe.net wrote:
>> Just sitting around doing nothing I'm seeing 30% loss to my next hop.
>> 
>> # ifconfig iwm0
>> iwm0: flags=808843 mtu 1500
>>  lladdr 80:19:34:ab:ab:ab
>>  index 5 priority 4 llprio 3
>>  groups: wlan egress
>>  media: IEEE802.11 autoselect (HT-MCS3 mode 11n)
>>  status: active
>>  ieee80211: nwid WIFI-NET chan 1 bssid 6c:70:9f:XX:XX:XX 52% wpakey 
>> wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
>>  inet 192.168.1.227 netmask 0xff00 broadcast 192.168.1.255
>> # ping -qc 30 192.168.1.1
>> PING 192.168.1.1 (192.168.1.1): 56 data bytes
>> 
>> --- 192.168.1.1 ping statistics ---
>> 30 packets transmitted, 21 packets received, 30.0% packet loss
>> round-trip min/avg/max/std-dev = 2.092/5.420/10.804/2.673 ms
>> 
>> 
>> What exact model do you have of the 3160? Maybe I can try and source one
>> and give it a try.
>
>I doubt it would make a difference. This doesn't look like a hardware
>defect, given that your run(4) device was also unhappy.
>
>My guess would be that the channel is noisy. Try to move your AP to
>another channel, like channel 6 or channel 11. And if your AP can use
>the 5 GHz band (channel 36 and up) that might help a lot more.

No doubt there's a lot of radio traffic where I'm located.

However, every other device on my network sees my 5 Ghz ssid except for
the OpenBSD machine. I'd expect to see the ssid WIFI-NET-5G, which is on
channel 132 of an Apple Airport Extreme 802.11ac. Instead, I only see 
WIFI-NET (moved to channel 7 purposefully for testing).

# ifconfig iwm0 up
# ifconfig iwm0 scan
iwm0: flags=8843 mtu 1500
lladdr 80:19:34:ab:ab:ab
index 5 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect
status: no network
ieee80211: nwid ""
nwid "Kelly's Killer Crib" chan 3 bssid 88:d7:f6:XX:XX:XX 55% 
HT-MCS15 privacy,short_slottime,wpa2 
nwid GJMD chan 9 bssid 60:45:cb:XX:XX:XX 46% HT-MCS23 
privacy,short_slottime,radio_measurement,wpa2 
nwid WIFI-NET chan 7 bssid 6c:70:9f:YY:YY:YY 40% HT-MCS23 
privacy,spectrum_mgmt,radio_measurement,wpa2 
nwid "HP-Print-1F-ENVY 5530 series" chan 11 bssid 
fc:15:b4:XX:XX:XX 40% 54M privacy,short_preamble,short_slottime,wpa2 
nwid "Kelly's Killer Crib_5G" chan 44 bssid 88:d7:f6:XX:XX:XX 
34% HT-MCS15 privacy,spectrum_mgmt,short_slottime,wpa2 

Trying to manually monitor channel 132, I get an error, SIOCS80211CHANNEL.

# ifconfig iwm0
iwm0: flags=8802 mtu 1500
lladdr 80:19:34:ab:ab:ab
index 5 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect
status: no network
ieee80211: nwid ""
# ifconfig iwm0 mediaopt monitor
# echo $?
0
# ifconfig iwm0 chan 132
ifconfig: SIOCS80211CHANNEL: Invalid argument

Dmesg shows it's a 7260 with good firmware.

# dmesg|grep iwm
iwm0 at pci5 dev 0 function 0 "Intel AC 7260" rev 0xc3, msi
iwm0: hw rev 0x140, fw ver 17.3216344376.0, address 80:19:34:ab:ab:ab

Even after a clean reboot I can't bring the interface up in monitor mode
and join anything other than channels 1-11.

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

[Stefan Sperling]

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

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

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

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

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

To go back to regular client mode:

ifconfig iwm0 -mediaopt monitor
ifconfig iwm0 -chan

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

[readme]

On Mon, Mar 14, 2022 at 09:42:37PM +0100, Stefan Sperling wrote:
>On Mon, Mar 14, 2022 at 03:05:00PM -0500, rea...@catastrophe.net wrote:
>> On Mon, Mar 14, 2022 at 08:58:01PM +0100, Stefan Sperling wrote:
>> >On Mon, Mar 14, 2022 at 02:34:29PM -0500, rea...@catastrophe.net wrote:
>> >> Well, even after adding iwm0 I notice high latency and packet loss 
>> >> anywhere
>> >> from 15-50%.  This occurs randomly when the device is either 2m, 10m, or 
>> >> 30m
>> >> away from the access point. I did testing to verify I'm seeing 65-80% 
>> >> signal
>> >> strength during some of the testing, but there's still loss even at that
>> >> strength.
>> >> 
[..]
>> >That is not expected.
>> >The driver is working fine in general and connections should be stable.
>> >
[..]
>The closest equivalent to your setup I have here are a 3160
>minipcie card (same as the 7260 but with only 1 Tx/Rx chain
>each instead of 2, i.e. no MIMO), and an APU2.
>
>I did a quick test with a snapshot I built 4 days ago.
>
>iwm0 at pci1 dev 0 function 0 "Intel AC 3160" rev 0x83, msi
>iwm0: hw rev 0x160, fw ver 17.3216344376.0, address b4:6d:83:2b:95:a0
>
>I don't see any packet loss.
>This is the 3160 sending to a host behind the AP with tcpbench:
>
>Conn:   1 Mbps:  109.417 Peak Mbps:  109.425 Avg Mbps:  109.417
>   11035   13544592  108.248  100.00%
>Conn:   1 Mbps:  108.248 Peak Mbps:  109.425 Avg Mbps:  108.248
>   12035   13674912  109.399  100.00%
>Conn:   1 Mbps:  109.399 Peak Mbps:  109.425 Avg Mbps:  109.399
>   13049   13732832  108.346  100.00%
>Conn:   1 Mbps:  108.346 Peak Mbps:  109.425 Avg Mbps:  108.346
>   14055   13685048  108.936  100.00%
>Conn:   1 Mbps:  108.936 Peak Mbps:  109.425 Avg Mbps:  108.936
>   15057   13638712  108.892  100.00%
>Conn:   1 Mbps:  108.892 Peak Mbps:  109.425 Avg Mbps:  108.892
>^C
>--- kipo tcpbench statistics ---
>194605408 bytes sent over 15.537 seconds
>bandwidth min/avg/max/std-dev = 51.155/99.968/109.425/15.694 Mbps
>
># ifconfig iwm0
>iwm0: 
>flags=a48843lladdr b4:6d:83:d4:b0:66
>index 1 priority 4 llprio 3
>groups: wlan egress
>media: IEEE802.11 autoselect (HT-MCS7 mode 11n)
>status: active
>ieee80211: join foo chan 36 bssid 00:85:1b:d2:e2:35 74% wpakey 
> wpaprotop

I'm jealous!

Just sitting around doing nothing I'm seeing 30% loss to my next hop.

# ifconfig iwm0
iwm0: flags=808843 mtu 1500
lladdr 80:19:34:ab:ab:ab
index 5 priority 4 llprio 3
groups: wlan egress
media: IEEE802.11 autoselect (HT-MCS3 mode 11n)
status: active
ieee80211: nwid WIFI-NET chan 1 bssid 6c:70:9f:XX:XX:XX 52% wpakey 
wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
inet 192.168.1.227 netmask 0xff00 broadcast 192.168.1.255
# ping -qc 30 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes

--- 192.168.1.1 ping statistics ---
30 packets transmitted, 21 packets received, 30.0% packet loss
round-trip min/avg/max/std-dev = 2.092/5.420/10.804/2.673 ms


What exact model do you have of the 3160? Maybe I can try and source one
and give it a try.

Thanks.

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

[Stefan Sperling]

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

Sorry, not sure what could be wrong.

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

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

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

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

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

# ifconfig iwm0
iwm0: flags=a48843

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

[readme]

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

I tried in 2 APU4 devices and the same issue happens.

Unfortunately I've got no other hardware to test with at this time.

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

[Stefan Sperling]

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

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

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

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

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

[readme]

On Mon, Mar 14, 2022 at 10:34:23AM -0500, rea...@catastrophe.net wrote:
>On Mon, Mar 14, 2022 at 12:43:57AM -, Stuart Henderson wrote:
>>On 2022-03-14, rea...@catastrophe.net  wrote:
>If not, consider hunting down a mini PCIe iwm(4) 7260 card, or an
>M.2 AX200 iwx(4) card with an adapter from M.2 to mini PCIe.
>Both would need compatible pigtails and antennas as well.
>>>
>>> So I tried one obtained from here [1] but it sadly doesn't even show up in a
>>> dmesg [2].
>>
>>Make sure it is in J15. J13 is USB/mSATA, J14 is USB-only (wired to the SIM
>>slot), J15 is full miniPCIE (no SIM).
>
>That did the trick; thanks Stuart.

Well, even after adding iwm0 I notice high latency and packet loss anywhere
from 15-50%.  This occurs randomly when the device is either 2m, 10m, or 30m
away from the access point. I did testing to verify I'm seeing 65-80% signal
strength during some of the testing, but there's still loss even at that
strength.

For now I'll hang an iogear GWU637 off em0 and bridge to the wireless net
using that. Maybe things will get better with iwm(4) in the future.

Re: Latency with run0 interface

[readme]

On Mon, Mar 14, 2022 at 12:43:57AM -, Stuart Henderson wrote:
>On 2022-03-14, rea...@catastrophe.net  wrote:
If not, consider hunting down a mini PCIe iwm(4) 7260 card, or an
M.2 AX200 iwx(4) card with an adapter from M.2 to mini PCIe.
Both would need compatible pigtails and antennas as well.
>>
>> So I tried one obtained from here [1] but it sadly doesn't even show up in a
>> dmesg [2].
>
>Make sure it is in J15. J13 is USB/mSATA, J14 is USB-only (wired to the SIM
>slot), J15 is full miniPCIE (no SIM).

That did the trick; thanks Stuart.

Also, reading schematics is a good thing!



- Cat Man

Re: Latency with run0 interface

[Stuart Henderson]

On 2022-03-14, rea...@catastrophe.net  wrote:
>>>If not, consider hunting down a mini PCIe iwm(4) 7260 card, or an
>>>M.2 AX200 iwx(4) card with an adapter from M.2 to mini PCIe.
>>>Both would need compatible pigtails and antennas as well.
>
> So I tried one obtained from here [1] but it sadly doesn't even show up in a
> dmesg [2].

Make sure it is in J15. J13 is USB/mSATA, J14 is USB-only (wired to the SIM
slot), J15 is full miniPCIE (no SIM).

Re: Latency with run0 interface

[readme]

On Fri, Mar 11, 2022 at 02:41:05PM -0600, rea...@catastrophe.net wrote:
>On Fri, Mar 11, 2022 at 09:01:41PM +0100, Stefan Sperling wrote:
>>On Fri, Mar 11, 2022 at 10:57:56AM -0600, rea...@catastrophe.net wrote:
>>> I'm using a Panda Express USB WiFi dongle on a PC Engines apu4 machine.
>>
>>This is a strange choice on an APU. Such dongles are really a last
>>resort, they tend to suffer from cooling issues and small antennas,
>>and OpenBSD only runs them in 11g mode rather than 11n mode.
>
>It was a pretty bad choice.
>
>>Are your APU's minipci slots already populated?
>
>Just one with a mSATA drive.
>
>>If not, consider hunting down a mini PCIe iwm(4) 7260 card, or an
>>M.2 AX200 iwx(4) card with an adapter from M.2 to mini PCIe.
>>Both would need compatible pigtails and antennas as well.

So I tried one obtained from here [1] but it sadly doesn't even show up in a
dmesg [2].

Maybe I got the wrong card?

[1] Intel 7260.HMW Dual Band Wireless-AC 7260 Network Adapter PCI

Express Half Mini Card 802.11 b/a/g/n/ac



[2] dmesg:

OpenBSD 7.0 (GENERIC.MP) #5: Mon Jan 31 09:09:02 MST 2022

r...@syspatch-70-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4259835904 (4062MB)
avail mem = 4114698240 (3924MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xcfe83040 (13 entries)
bios0: vendor coreboot version "v4.14.0.6" date 11/04/2021
bios0: PC Engines apu4
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT DRTM HPET
acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) 
UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD GX-412TC SOC, 998.28 MHz, 16-30-01
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,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD GX-412TC SOC, 998.14 MHz, 16-30-01
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,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD GX-412TC SOC, 998.14 MHz, 16-30-01
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,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD GX-412TC SOC, 998.14 MHz, 16-30-01
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,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins
ioapic1 at 

Re: Latency with run0 interface

[Stuart Henderson]

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

Note that miniPCIE use U.FL (IPEX), M.2 (NGFF) cards use MHF4 (IPEX4)
connectors. They look quite similar in size (especially if you don't
have both types to compare) so make sure you use the right pigtail for
the card - trying to use the wrong one will damage at least the
connector on the pigtail if not also the card.

Re: Latency with run0 interface

[Stefan Sperling]

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

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

Re: Latency with run0 interface

[readme]

On Fri, Mar 11, 2022 at 09:01:41PM +0100, Stefan Sperling wrote:
>On Fri, Mar 11, 2022 at 10:57:56AM -0600, rea...@catastrophe.net wrote:
>> I'm using a Panda Express USB WiFi dongle on a PC Engines apu4 machine.
>
>This is a strange choice on an APU. Such dongles are really a last
>resort, they tend to suffer from cooling issues and small antennas,
>and OpenBSD only runs them in 11g mode rather than 11n mode.

It was a pretty bad choice.

>Are your APU's minipci slots already populated?

Just one with a mSATA drive.

>If not, consider hunting down a mini PCIe iwm(4) 7260 card, or an
>M.2 AX200 iwx(4) card with an adapter from M.2 to mini PCIe.
>Both would need compatible pigtails and antennas as well.

Thanks, I'll get a 7260. Do the half mini cards have any problems vs.
the full PCI-e cards? 

Re: Latency with run0 interface

[Stefan Sperling]

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

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

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

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

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

Latency with run0 interface

[readme]

I'm using a Panda Express USB WiFi dongle on a PC Engines apu4 machine.

Basic SSH sessions to the device run decent, but when any sort of data
transfer is done to the device (even serving back pfstat images from the
device's local httpd), I notice high latency.

# ifconfig run0
run0: 
flags=a48843
 mtu 1500
lladdr 9c:ef:d5:ca:cc:fc
index 7 priority 4 llprio 3
groups: wlan egress
media: IEEE802.11 autoselect (DS1 mode 11g)
status: active
ieee80211: nwid WIFI-NET chan 1 bssid xx:xx:xx:xx:xx:14 -51dBm wpakey 
wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
inet6 fe80:::::ccfc%run0 prefixlen 64 scopeid 0x7
inet 192.168.1.8 netmask 0xff00 broadcast 192.168.1.255


While running ping when downloading ~ 300k of images from httpd, notice the
latency.  This latency only occurs when doing any sort of activity over the
run0 link.


# ping -qc 5 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes

--- 192.168.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 17.725/1783.267/3373.620/1402.106 ms


Is there a better USB dongle that doesn't have these issues?

Thanks!

-Cat Manual