What's the first line in dmesg?
@kroon040 I've unpacked the sysupgrade image from the images I built yesterday (the ones up now), to be sure that all the drivers are in there. So make sure you're using that one. Checksum is 180de537f6d440983a96e19797ee7644f2eed1efd059f18059cdb2fc976d7abd for the sysupgrade image.
Grepping for mt76 shows this:
$ grep "Package: kmod-mt76" status
Package: kmod-mt7615e
Package: kmod-mt7615-common
Package: kmod-mt7603
Package: kmod-mt7663-firmware-ap
Package: kmod-mt76-core
I'm going back to the stock rom, the is not working easy.
What is de best way to go back, download the binfile from tplink and than what option?
Please choose the operation:
1: Load system code to SDRAM via TFTP.
2: Load the whole FLASH image then write to Flash(Skip U-Boot & cal-data) via TFTP.
6: Load the whole FLASH image then write to Flash(do NOT skip U-Boot & cal-data) via TFTP.
3: Boot system code via Flash (default).
4: Entr boot command line interface.
7: Load Boot Loader code then write to Flash via Serial.
9: Load Boot Loader code then write to Flash via TFTP.
I have no idea what file format those options expect. I would suggest you boot into OpenWrt and use a firmware file converted with tplink-safeloader to flash back to stock.
Users working on the Acher A6v3/C6U were able to track the ethernet issue down to the reset controller:
I've (force) pushed a temporary fix to the EAP235-Wall branch until we can figure a proper fix for this reset controller code. In the meantime, testing the EAP235-Wall port should be much less of a hassle 
2 Likes
I'll be filling up holes I made for my EAPs this afternoon but I'll build another image and test myself. Thanks @svanheule!
With the EEPROM patch (as mentioned in the Archer A6 v3 support thread) the 5 GHz shows higher power at least:
Nevermind me, the original tests were run with a Fast Ethernet switch running in between 
Testing below was done with iperf3, single stream, downstream from a wired x86 server. Gigabit all around
Setup #1: AP on floor above
Signal on the phone hovers around -70 dBm (situated diagonally under the AP, a floor below, with a wooden floor and a thin brick wall in between), noise above 90 dBm as you can see from the screenshot. With the original tests, with a forgotten Fast Ethernet switch in between, bitrate fluctuated heavily here, to the point of completely stalling. With that switch taken out that didn't reproduce.
Iperf tests run from the laptop on the same spot:
$ iperf3 -c 10.0.0.10
Connecting to host 10.0.0.10, port 5201
[ 5] local 10.0.0.5 port 40668 connected to 10.0.0.10 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 17.4 MBytes 146 Mbits/sec 0 655 KBytes
[ 5] 1.00-2.00 sec 16.2 MBytes 136 Mbits/sec 0 923 KBytes
[ 5] 2.00-3.00 sec 15.0 MBytes 126 Mbits/sec 0 1.05 MBytes
[ 5] 3.00-4.00 sec 15.0 MBytes 126 Mbits/sec 0 1.16 MBytes
[ 5] 4.00-5.00 sec 15.0 MBytes 126 Mbits/sec 0 1.21 MBytes
[ 5] 5.00-6.00 sec 16.2 MBytes 136 Mbits/sec 0 1.28 MBytes
[ 5] 6.00-7.00 sec 16.2 MBytes 136 Mbits/sec 0 1.53 MBytes
[ 5] 7.00-8.00 sec 15.0 MBytes 126 Mbits/sec 0 1.53 MBytes
[ 5] 8.00-9.00 sec 15.0 MBytes 126 Mbits/sec 0 1.53 MBytes
[ 5] 9.00-10.00 sec 16.2 MBytes 136 Mbits/sec 0 1.53 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 157 MBytes 132 Mbits/sec 0 sender
[ 5] 0.00-10.03 sec 154 MBytes 129 Mbits/sec receiver
iperf Done.
$ iperf3 -c 10.0.0.10
Connecting to host 10.0.0.10, port 5201
[ 5] local 10.0.0.5 port 40684 connected to 10.0.0.10 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 17.9 MBytes 150 Mbits/sec 0 915 KBytes
[ 5] 1.00-2.00 sec 15.0 MBytes 126 Mbits/sec 0 1.24 MBytes
[ 5] 2.00-3.00 sec 16.2 MBytes 136 Mbits/sec 0 1.56 MBytes
[ 5] 3.00-4.00 sec 15.0 MBytes 126 Mbits/sec 0 1.56 MBytes
[ 5] 4.00-5.00 sec 16.2 MBytes 136 Mbits/sec 0 1.76 MBytes
[ 5] 5.00-6.00 sec 15.0 MBytes 126 Mbits/sec 0 1.76 MBytes
[ 5] 6.00-7.00 sec 13.8 MBytes 115 Mbits/sec 0 1.85 MBytes
[ 5] 7.00-8.00 sec 16.2 MBytes 136 Mbits/sec 0 2.00 MBytes
[ 5] 8.00-9.00 sec 15.0 MBytes 126 Mbits/sec 0 2.00 MBytes
[ 5] 9.00-10.00 sec 15.0 MBytes 126 Mbits/sec 0 2.00 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 155 MBytes 130 Mbits/sec 0 sender
[ 5] 0.00-10.03 sec 153 MBytes 128 Mbits/sec receiver
Setup #2: line of sight
These tests are run right in front of the AP, at a distance of give or take two meters. Cutouts seem to be gone. Signal hovers around 50 dBm, noise still over 90 dBm. Still a lot of retries though (Retr colum), not sure how good that is.
$ iperf3 -c 10.0.0.10
Connecting to host 10.0.0.10, port 5201
[ 5] local 10.0.0.5 port 40820 connected to 10.0.0.10 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 44.7 MBytes 375 Mbits/sec 0 1.34 MBytes
[ 5] 1.00-2.00 sec 47.5 MBytes 398 Mbits/sec 0 1.59 MBytes
[ 5] 2.00-3.00 sec 52.5 MBytes 440 Mbits/sec 0 1.70 MBytes
[ 5] 3.00-4.00 sec 52.5 MBytes 440 Mbits/sec 0 1.88 MBytes
[ 5] 4.00-5.00 sec 50.0 MBytes 419 Mbits/sec 0 1.99 MBytes
[ 5] 5.00-6.00 sec 50.0 MBytes 419 Mbits/sec 0 2.09 MBytes
[ 5] 6.00-7.00 sec 52.5 MBytes 440 Mbits/sec 0 2.09 MBytes
[ 5] 7.00-8.00 sec 52.5 MBytes 440 Mbits/sec 0 2.09 MBytes
[ 5] 8.00-9.00 sec 48.8 MBytes 409 Mbits/sec 0 2.09 MBytes
[ 5] 9.00-10.00 sec 52.5 MBytes 440 Mbits/sec 0 2.09 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 503 MBytes 422 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 500 MBytes 419 Mbits/sec receiver
iperf Done.
$ iperf3 -c 10.0.0.10
Connecting to host 10.0.0.10, port 5201
[ 5] local 10.0.0.5 port 40834 connected to 10.0.0.10 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 46.8 MBytes 392 Mbits/sec 0 1.17 MBytes
[ 5] 1.00-2.00 sec 53.8 MBytes 451 Mbits/sec 0 1.78 MBytes
[ 5] 2.00-3.00 sec 47.5 MBytes 398 Mbits/sec 0 1.78 MBytes
[ 5] 3.00-4.00 sec 47.5 MBytes 398 Mbits/sec 0 1.88 MBytes
[ 5] 4.00-5.00 sec 47.5 MBytes 398 Mbits/sec 0 2.08 MBytes
[ 5] 5.00-6.00 sec 47.5 MBytes 398 Mbits/sec 0 2.18 MBytes
[ 5] 6.00-7.00 sec 51.2 MBytes 430 Mbits/sec 0 2.18 MBytes
[ 5] 7.00-8.00 sec 50.0 MBytes 419 Mbits/sec 0 2.18 MBytes
[ 5] 8.00-9.00 sec 50.0 MBytes 419 Mbits/sec 0 2.30 MBytes
[ 5] 9.00-10.00 sec 50.0 MBytes 419 Mbits/sec 0 2.30 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 492 MBytes 413 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 489 MBytes 410 Mbits/sec receiver
iperf Done.
2 Likes
It's better than before, but doesn't sound great either. If you have time, can you also compare with stock firmware?
Yeah still have one running stock firmware, will do. Just tried an scp copy, seeing just above 11 MBps on a big transfer, wired to wireless, Intel 8260AC two-stream client. So that matches iperf numbers.
1 Like
With 2x2:2 MIMO, 80 MHz channels. shouldn´t you easily get 300++ Mbps?
That's why we're testing and going to compare to stock 
@svanheule This is with the OEM firmware, unfortunately no way to select WPA3, but I doubt it would impact measurements much. Same channel (36, 80 MHz width).
Setup #1
Bitrate stays pretty stable, and no stalling connections. Comparably low bitrate, but that' s to be expected with the materials in between.
$ iperf3 -c 10.0.0.10
Connecting to host 10.0.0.10, port 5201
[ 5] local 10.0.0.5 port 39906 connected to 10.0.0.10 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 17.1 MBytes 144 Mbits/sec 0 666 KBytes
[ 5] 1.00-2.00 sec 15.0 MBytes 126 Mbits/sec 0 823 KBytes
[ 5] 2.00-3.00 sec 15.0 MBytes 126 Mbits/sec 0 909 KBytes
[ 5] 3.00-4.00 sec 16.2 MBytes 136 Mbits/sec 0 1.09 MBytes
[ 5] 4.00-5.00 sec 18.8 MBytes 157 Mbits/sec 0 1.09 MBytes
[ 5] 5.00-6.00 sec 16.2 MBytes 136 Mbits/sec 0 1.15 MBytes
[ 5] 6.00-7.00 sec 17.5 MBytes 147 Mbits/sec 0 1.15 MBytes
[ 5] 7.00-8.00 sec 17.5 MBytes 147 Mbits/sec 0 1.15 MBytes
[ 5] 8.00-9.00 sec 17.5 MBytes 147 Mbits/sec 0 1.21 MBytes
[ 5] 9.00-10.00 sec 16.2 MBytes 136 Mbits/sec 0 1.28 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 167 MBytes 140 Mbits/sec 0 sender
[ 5] 0.00-10.01 sec 164 MBytes 137 Mbits/sec receiver
iperf Done.
$ iperf3 -c 10.0.0.10
Connecting to host 10.0.0.10, port 5201
[ 5] local 10.0.0.5 port 39926 connected to 10.0.0.10 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 17.7 MBytes 148 Mbits/sec 0 581 KBytes
[ 5] 1.00-2.00 sec 16.2 MBytes 136 Mbits/sec 0 867 KBytes
[ 5] 2.00-3.00 sec 15.0 MBytes 126 Mbits/sec 0 963 KBytes
[ 5] 3.00-4.00 sec 15.0 MBytes 126 Mbits/sec 0 1018 KBytes
[ 5] 4.00-5.00 sec 10.0 MBytes 83.9 Mbits/sec 1 737 KBytes
[ 5] 5.00-6.00 sec 13.8 MBytes 115 Mbits/sec 0 813 KBytes
[ 5] 6.00-7.00 sec 12.5 MBytes 105 Mbits/sec 0 887 KBytes
[ 5] 7.00-8.00 sec 12.5 MBytes 105 Mbits/sec 0 913 KBytes
[ 5] 8.00-9.00 sec 12.5 MBytes 105 Mbits/sec 0 949 KBytes
[ 5] 9.00-10.00 sec 12.5 MBytes 105 Mbits/sec 0 986 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 138 MBytes 115 Mbits/sec 1 sender
[ 5] 0.00-10.01 sec 135 MBytes 113 Mbits/sec receiver
iperf Done.
Setup #2
$ iperf3 -c 10.0.0.10
Connecting to host 10.0.0.10, port 5201
[ 5] local 10.0.0.5 port 39430 connected to 10.0.0.10 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 42.4 MBytes 356 Mbits/sec 0 1.07 MBytes
[ 5] 1.00-2.00 sec 47.5 MBytes 398 Mbits/sec 0 1.29 MBytes
[ 5] 2.00-3.00 sec 48.8 MBytes 409 Mbits/sec 0 1.36 MBytes
[ 5] 3.00-4.00 sec 48.8 MBytes 409 Mbits/sec 0 1.51 MBytes
[ 5] 4.00-5.00 sec 50.0 MBytes 419 Mbits/sec 0 1.69 MBytes
[ 5] 5.00-6.00 sec 50.0 MBytes 419 Mbits/sec 0 1.80 MBytes
[ 5] 6.00-7.00 sec 51.2 MBytes 430 Mbits/sec 0 1.89 MBytes
[ 5] 7.00-8.00 sec 52.5 MBytes 440 Mbits/sec 0 1.99 MBytes
[ 5] 8.00-9.00 sec 51.2 MBytes 430 Mbits/sec 0 2.09 MBytes
[ 5] 9.00-10.00 sec 52.5 MBytes 440 Mbits/sec 0 2.20 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 495 MBytes 415 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 492 MBytes 412 Mbits/sec receiver
iperf Done.
$ iperf3 -c 10.0.0.10
Connecting to host 10.0.0.10, port 5201
[ 5] local 10.0.0.5 port 39598 connected to 10.0.0.10 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 50.7 MBytes 425 Mbits/sec 0 1.28 MBytes
[ 5] 1.00-2.00 sec 46.2 MBytes 388 Mbits/sec 0 1.41 MBytes
[ 5] 2.00-3.00 sec 46.2 MBytes 388 Mbits/sec 0 1.60 MBytes
[ 5] 3.00-4.00 sec 46.2 MBytes 388 Mbits/sec 0 1.68 MBytes
[ 5] 4.00-5.00 sec 50.0 MBytes 419 Mbits/sec 0 1.68 MBytes
[ 5] 5.00-6.00 sec 51.2 MBytes 430 Mbits/sec 70 935 KBytes
[ 5] 6.00-7.00 sec 52.5 MBytes 440 Mbits/sec 0 1007 KBytes
[ 5] 7.00-8.00 sec 52.5 MBytes 440 Mbits/sec 0 1.02 MBytes
[ 5] 8.00-9.00 sec 52.5 MBytes 440 Mbits/sec 0 1.05 MBytes
[ 5] 9.00-10.00 sec 50.0 MBytes 419 Mbits/sec 0 1.08 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 498 MBytes 418 Mbits/sec 70 sender
[ 5] 0.00-10.02 sec 496 MBytes 415 Mbits/sec receiver
iperf Done.
No discernable difference from what I can see (same for signal, by the way: I'm right in front of the AP and the signal icon shows 4 bars out of five).
1 Like
It seems that TP-Link improved wireless performance with latest firmware (https://www.tp-link.com/de/support/download/eap235-wall/#Firmware), i.e. [EAP235-Wall(EU)_V1_1.0.2 Build 2020091](https://static.tp-link.com/2020/202011/20201103/EAP235-Wall(EU)_V1_1.0.2 Build 20200917.zip)
1 Like
That's the one pre-installed on the AP: 1.0.2 Build 20200917 Rel. 54331(4555).
I thought maybe the fact it was on its side above might play a role, but it doesn't. Just rotated it 45* and no difference in signal or throughput. Transmit power is the maximum advertised (which is 24 dBm but that includes the gain from the antenna, which is said to be 4 dBi).
Edit: F*** me, I still had a Fast Ethernet switch sitting in between the x86 box and the PoE switch that I totally forgot about
@CBokey Nevermind, there was a Fast Ethernet switch still sitting in between, on my testing rig...
@svanheule It looks to me like performance is very similar between stock and OpenWrt, so that's good news I'd say. I don't think you'll see much higher than what this is pushing with line of sight (it's basically what 866 Mbps link speed can handle more or less).
1 Like
AP had been up for ~11h and the 5 GHz crapped out apparently around 6:30 this morning. Wifi status shows the radio as being up and running still but the signal is nowhere to be seen. Seeing lots of these in the logs:
Mon Feb 1 06:27:11 2021 kern.err kernel: [21304.406938] mt7615e 0000:02:00.0: Message 73 (seq 11) timeout
Mon Feb 1 06:27:37 2021 kern.err kernel: [21331.030765] mt7615e 0000:02:00.0: Message 73 (seq 12) timeout
Mon Feb 1 06:28:04 2021 kern.err kernel: [21357.654598] mt7615e 0000:02:00.0: Message 73 (seq 13) timeout
Mon Feb 1 06:28:30 2021 kern.err kernel: [21384.278429] mt7615e 0000:02:00.0: Message 73 (seq 14) timeout
Mon Feb 1 06:28:57 2021 kern.err kernel: [21410.902258] mt7615e 0000:02:00.0: Message 73 (seq 15) timeout
[...]
Mon Feb 1 07:21:19 2021 kern.err kernel: [24552.513618] mt7615e 0000:02:00.0: Message 73 (seq 13) timeout
Mon Feb 1 07:21:45 2021 kern.err kernel: [24579.137441] mt7615e 0000:02:00.0: Message 73 (seq 14) timeout
Mon Feb 1 07:22:12 2021 kern.err kernel: [24605.761266] mt7615e 0000:02:00.0: Message 73 (seq 15) timeout
Mon Feb 1 07:22:39 2021 kern.err kernel: [24632.385089] mt7615e 0000:02:00.0: Message 73 (seq 1) timeout
This goes on for like an hour and then it stops, and the radio is gone.
Edit: I found an MT76 issue on GitHub referencing similar timeouts and there it's suggested the chip temperature might play a role. Have reduced TX power to 20 dBm for now, will see if that changes anything. Device is on its side as well for now (testing setup), maybe that plays a role as well.
Edit 2: Timeouts again, less than two and a half hours after reboot. Radio gone again (still TX power at 21 dBm but AP is now positioned upright, like it would be mounted against the wall). OpenWrt will try restarting the radio a few times but it will give up eventually:
"radio1": {
"up": false,
"pending": false,
"autostart": true,
"disabled": false,
"retry_setup_failed": true,
"config": {
"channel": "36",
"hwmode": "11a",
"path": "1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0",
"htmode": "VHT80",
"require_mode": "n",
"cell_density": 0,
"txpower": 20
},
I remember seeing references to thermal management somewhere, but I'm not sure if it was the vendor firmware boot log. I'll check in a few hours if I can find it back.
1 Like
I talked to nbd on IRC in the meantime and he suggested to try with an older mt76 driver, which is what I'm doing at the moment.
For the record: reducing TX power to 20 dBm didn't seem to make any difference.
A status update:
- I haven't been able to track down the message 73 timeout to a specific commit. The issue seems to take longer to pop up now. Llast time was over 6 hours, and I've had multiple bisects up for 12 to 24h, no errors to be seen.
- The MT7613 radio does support DFS channels but that has been disabled in the mt76 driver, maybe/presumably because of issues with radar detection. I talked to one of the mt76 developers and he explained me how to enable DFS, but I am seeing the driver detect 'radars' on channel 36 (another EAP235 deployed for testing) and channel 52 (a production AP here in the house). Channel 36 to 48 are not DFS channels, so it's pretty weird to see the driver think it's seeing a radar event there.
I'd say device support is there (thanks @svanheule!) but it is not completely usable yet - there's a few pending patches that need to be merged (the EEPROM stuff, the MT7621 SoC reset stuff) before device support can be added to master, and then we're still left with the present state of MT7613 (the message 73 timeout error if it sticks, and the DFS channels being unusuable for now).
Has anything changed w.r.t. support for this device in an upcoming version (or snapshot)? I am considering buying it but would like to run OpenWRT on it.
Device support has been merged, and will be available in the upcoming 21.02 release.
DFS support is still missing from mt76, but non-DFS 5GHz channels should work.
2 Likes
Perfect, that's all I needed to know. Thanks!