Re: Latency and loss persist with iwm0 (Was Re: Latency with run0 interface)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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?