Hi, I recently setup a VM of OpenWRT in ESXi with a passthru of an MT7915e I purchased from AsiaRF. It's working, kinda. I get very weak signal at the other side of the house, and I can't get devices to connect and stay connected (if they connect at all). I've been doing a lot of Google searching trying to pin down the issue, but no such luck. The tx power in the wireless config only goes as high as 23 dbm, and i don't see anything else to modify. Any suggestions? Attached is a screenshot from my tablet of the WiFi in the house. Both birdsofprey and residentevil are an existing Netgear router, with no connectivity issues except reliable throughout. Test2.4 and test5 are the OpenWRT VM.
A few questions / suggestions:
-
What's the actual name of the device you are working with? Or is it x86 with mt7915 pcie card?
-
What version of OpenWrt are you running? Is this master snapshot?
-
I would suggest to first test OpenWrt vanilla to eliminate any slowdowns/incompatibilities caused by your ESXi VM.
-
It is not useful to compare your OpenWrt device with other routers (Of course, if you really wanted to know, they would have to be located in the same spot, with same clients and same config). It's apples and oranges. Better would be to compare your device with different versions of software running on it. I recommend: a) with OpenWrt, b) with stock OEM and c) OpenWrt in VM.
-
Your picture shows that your test2.4 is on same channel than your existing devices. Channel 1 and 3 overlapp. This causes interference and should be avoided. Try different channels.
-
In general, there might be lots of interference, as your scanner finds 13 ssids in 2.4 GHz and 5 SSIDs in 5 GHz bands.
-
I think you are using mixed mode of encryption. Try to avoid this. Wpa is outdated and some devices have trouble connecting to it. Use wpa2 psk (should be stable) or if possible try to use wpa3 psk, if your client devices support it.Apologies. You do not used mixed mode of encryption. My bad. I looked at the wrong device. Might be worth a shot to try other modes of encryption. Maybe your client devices do not support wpa2. -
Configuration is important. First, access your device via SSH (See how: https://openwrt.org/docs/guide-quick-start/sshadministration)
Then please copy the output of the following commands and post it here using the "Preformatted text </> " button.
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
1 Like
- X86 VM on ESXi
- Ran both master and nightly snapshots, no change.
- Tested on a WRT32X before switching to a VM, wasn't successful setting it up. Can't test on the working RAX48 Netgear that currently supplies WiFi to the house.
- All devices are located in the same spot in the house, where all of the networked equipment is (the ESXi hypervisor host, both switches, and the WAPs).
- Tried different channels, no diff. If I don't use either channels 36-48, devices either won't see the MT7915e device, or will but refuse to connect with good performance.
- I always use WPA2 PSK (CCMP), which most of my devices accept with no issues from the previous WAPs.
cat /etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdf5:4e52:345b::/48'
option packet_steering '1'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
option mtu '9000'
option ipv6 '0'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.11'
option netmask '255.255.255.0'
option ip6assign '60'
option gateway '192.168.1.1'
list dns '192.168.1.2'
list dns '192.168.1.3'
option delegate '0'
config device
option name 'eth0'
option mtu '9000'
option ipv6 '0'
config device
option name 'phy0-ap0'
option ipv6 '0'
config device
option name 'phy1-ap0'
option ipv6 '0'
cat /etc/config/wireless
config wifi-device 'radio0'
option type 'mac80211'
option path 'pci0000:00/0000:00:15.0/0000:03:00.0'
option channel '7'
option band '2g'
option htmode 'HE40'
option txpower '26'
option country 'US'
option cell_density '0'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'test2.4'
option encryption 'psk2+ccmp'
option key ''
option ieee80211w '1'
config wifi-device 'radio1'
option type 'mac80211'
option path 'pci0000:00/0000:00:15.0/0000:03:00.0+1'
option channel '36'
option band '5g'
option htmode 'HE80'
option cell_density '0'
option country 'US'
option txpower '23'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'test5'
option encryption 'psk2+ccmp'
option key 'm'
option ieee80211w '1'
cat /etc/config/dhcp
config dnsmasq
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
option localservice '1'
option ednspacket_max '1232'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv4 'server'
option ignore '1'
option dynamicdhcp '0'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
cat /etc/config/firewall
config defaults
option syn_flood '1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
list network 'wan6'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
I'm trying both DD-WRT and OpenWRT in an VM on ESXi 7.0 with PCIe passthru of the device. The passthru works just fine, as far as I can tell. WiFi does technically work on this card, but the performance compared to my existing standalone RAX48 is questionable. Just trying to figure out did I order a sub-performing card.
I think your rax48 uses different hardware. Open it up and compare with your other device and you will see. Obviously performance might differ.
In your tests you use 20 MHz, which theoretically should have higher range than 160 MHz, but you could try 160 MHz nevertheless as some clients have had some uplink performance issues with 80 MHz channel bandwidths. Maybe 20 MHz channels have also issues.
Another thing to check is if you have set the countrycode. This is very important. Without, performance will be abysmal. You did set it to US. My bad. Should be alright then.
Okay, prefacing this with a request: please don't assume I know nothing about tech. Been using computers since before I could walk (dad worked for, and retired from TI/Raytheon. There was always a computer in the house.). Yes, obvs the RAX48 uses different hardware, not trying to direct compare to that, just noting it's the only device in the house that's producing any usable signal and throughput, which for three tested devices is odd to me.
Okay, back to the diagnostics. I can't get any better signal or throughput on 160MHz, and actually gave up on implementing it on the master snapshot because I couldn't get a usable channel. I'd test a channel, and no devices would connect, but if I set it to 80MHz on that same channel, devices would suddenly connect. I've again tested both the WRT32X and my x86 VM with both DD-WRT and OpenWRT and have gotten similar results, so I'm trying to find out if there's something I can tweak manually in the configs that may not be tweakable in the GUI (happens at times when you're setting up a GUI to do basic configs for many devices). I understand it may not be possible to address every use case, I'm just trying to see if 1) anyone else has had issues with the MT7915e chipset and usable bandwidth under what "should" be an average use case, and 2) if there is any documentation on the wireless config file I've just not found that has options in general and specifically to the MT7915e that I can test with?
If we assume the card is suboptimal (e.g. because the reach is lower than expected), then the necessary conclusion would be to buy new hardware or alternatively to change the location of your device or use cables instead.
Right now, there is no proof the card is suboptimal, nor for the card working well. To proof the later, you could provide throughput / latency tests (e.g. via Iperf. Check this out) for clients that are right next to your accesspoint. If then connectivity issues still exist, then obviously something is very wrong, but if you get great signal, then is that not proof that the hardware is ok?
If we assume the hardware is ok, but there are some edge cases with regard to latency / throughput / connectivity and reach, then that could potentially be fixed up to a certain degree with different software or different configuration. But only up to a certain degree. There are still hardware limits.
You could try various stuff like enabling / disabling software flow offloading or hardware flow offloading (network > firewall). You also can try to disable/enable packetsteering across all CPUs (network > interfaces > global network options).
You could try to bring down bufferbloat/latency via manipulating AQL queues as suggested here: Belkin RT3200/Linksys E8450 - AQL and WiFi Latency - #42 by patrakov
Roaming / meshing can have negative impact on throughput, latency, but you are not using this, as far as I am aware.
I have done connectivity tests right at the AP, when I first setup the card, and the connectivity is actually pretty good (not great, but usable). I didn't try flow offloading, but I have tried disabling/enabling packet steering with no noticeable effect. And yes, I'm not using a mesh network.
I'm going to try messing with flow offloading, and I'll look at the AQL stuff, but my primary concern really is the signal strength being far lower than it should be, and the effect that has on total throughput. The house isn't that big, and yes there are walls in the way of the furthest station, but no further than apartments I've lived in with tenants around me using their own APs (and all of the noise that generates).
I'm not trying to make less of the hardware or software, or make this more difficult than it needs to be, just trying to arm myself with knowledge to attempt to determine the reason why this wireless setup as a whole isn't performing as well as I think it should (emphasizing the word "think").
1 Like
By any chance, are there any error messages in the logs for the cases when clients disconnect or fail to connect?
(And what do you mean with "pretty good". Does it reach the 1200 Mbps?
I just tested and below is what I get on connect/disconnect using test5 (the 5GHz AP):
Mon Apr 24 16:28:03 2023 daemon.info hostapd: phy1-ap0: STA 96:3e:5e:d6:65:c7 IEEE 802.11: authenticated
Mon Apr 24 16:28:03 2023 daemon.info hostapd: phy1-ap0: STA 96:3e:5e:d6:65:c7 IEEE 802.11: associated (aid 1)
Mon Apr 24 16:28:03 2023 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED 96:3e:5e:d6:65:c7 auth_alg=open
Mon Apr 24 16:28:03 2023 daemon.info hostapd: phy1-ap0: STA 96:3e:5e:d6:65:c7 RADIUS: starting accounting session 002015BB8E4DE869
Mon Apr 24 16:28:03 2023 daemon.info hostapd: phy1-ap0: STA 96:3e:5e:d6:65:c7 WPA: pairwise key handshake completed (RSN)
Mon Apr 24 16:28:03 2023 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED 96:3e:5e:d6:65:c7
Mon Apr 24 16:29:29 2023 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED 96:3e:5e:d6:65:c7
So, no obvious errors from the system log that I can see.
When I say "pretty good", it's usable, but not 1200Mbps good.
Further pics to follow: the forum is warning me that i can only put 1 pic per post, I think.
Now, the working AP. I'm connected using my phone (same device as the previous two pics), right at the AP's location in the house.
This VM is running on a Dell R720 ESXi host. It's allocated 4CPUs and 2GB of RAM (way more than it'll use in this scenario). I intentionally did overkill on this VM to test it's ability to process and route WiFi traffic, with the intent to scale back or up if needed. Did the same with my pfSense router on the same host.
Also, I just tried the settings update on the AQL post (just the settings, not the patch). Here's the before: https://www.waveform.com/tools/bufferbloat?test-id=fdd0a964-c7f7-4836-abfc-5bdb3f7b3674
And the after: https://www.waveform.com/tools/bufferbloat?test-id=dd4b0211-e4d7-41ea-92c5-c478d2a14939
Oh, and for comparison, from my desktop which is ethernet-connected gigabit: https://www.waveform.com/tools/bufferbloat?test-id=d64ffd98-539d-4ab1-896a-cc0cb5522d8a
I might misremember but those cards might need to be pointed to their calibration data. No idea how that works though (on embedded it's stored on the flash of the device, not on the radio itself).
if this is right next to your AP, then this weak signal suggests something is very wrong.
silly question maybe, but what is the antenna setup like? are they dualband?
I've tried three different sets of antennae with this card. The adapter and the card are only able to use two antennae, and it was a cheapy PCIe adapter from Amazon, so i switched to a set that came with another WiFi6 card I tried to test with (Asus PCE-AC68, which didn't work in AP Mode), and that didn't work either (no improvement in signal or connection). So, I've tried using two of the antennae off the WRT32X I have (same, no improvement). I'm at a loss here. Maybe one or more of the studs on the adapter card are shorting leads on the MT7915e or something, dunno...
Been trying to find out how to add the calibration data, but can't find any good straightforward sources on this, and what I have found is targeted more toward hardware routers, not VMs... Still looking, but kinda stuck ATM.