I upgraded to a build with the latest ath10 firmware but I still saw some issues with the 5GHz. Then I realized that the EA6350 was using the same channel (36) as another access point in my home (Both were set to auto), so I hard coded both to use channels which should be separated by 80MHz to avoid any interference but still got issues. Finally gave up on it and switched off 5GHz on this router since 2.4GHz is working perfectly fine for me.
I have not noticed any issues at all on 2.4GHz, excellent throughput all the time.
I'm happy to help with testing, but this calibration board things sounds a bit out of my league 
5 days ago? Well, 5 days ago the ath10k-ct firmware got an big update.
Unfortunately, his site seems to be down. [https://www.candelatech.com] so unless someone finds a copy of QCA4019-firmware-5-ct-full-community-12.bin-lede.002 in his dl folder we need to wait.
-
Good is relative
. Are you sure the boarddata is the culprit and not the new firmware?As for update: We have sent updates to existing board data files before. For example, the RT-AC58U received a update and one of the OpenMesh was updated as well. So if the different boardData perform better, then go for it. I tried to look into the FW_EA6350v3_3.1.10. But it failed to extract. so can't help much there.
As for picking the right one. It's usually boardData0.bin and boardData1.bin. There can be different versions (FCC, IC, EU, ...) but any one of those should be fine. Probably the save choice is to compare the different boardDatas with their extracted radiopart from the ART partition and pick the one with the least amount of differences (which is hard since it's a binary).
-
same ID.
-
Yes, that would be swell.
Little bit OT: But maybe have a quick peek into https://forum.mikrotik.com/viewtopic.php?f=7&t=136002 (Mikrotik's ARM support forum - or any other part of that forum) to cool off. Because no matter what, it's going to be all buggy. https://forum.mikrotik.com/viewtopic.php?f=7&t=144776#p712447
I understand, @chunkeey, but it was working amazingly fine a week ago. I don't know what exactly happened but I have some interesting information.
If you go to Wireless in LuCI, you look at the associated stations, and you will see that the transmission rate is good. But the reception rate is awful.
I think this is because the stations can listen clearly the router but the router can't hear the stations so good. That made me think about the calibration board files.
Maybe the router sensitivity for RX is not the correct. I don't know, let me known what you think.
Also: for testing calibration files (as @anders said it's out of his/her league) you only need to flash a firmware. You have to do literally anything else.
@chunkeey hi mate need your help to revert back to the original firmware ,can you please help me ,pm me if you can thanks in advance
This is what I'm talking about:
As you can see the RX Rate is 12.0 Mbps (20 MHz width, really?). The TX Rate is 130.0 Mbps and 175.6 Mbps (not that good but 10 times the RX Rate). So the problem is in one direction. This issue is not related to interference as where I live (oh, this technological savvy country) there are 0 WiFi 5 GHz networks.
Well, a -111 dBm noise should be a proof of the fact that there are 0 wireless network using 5 GHz. I think that the router's sensitivity is not adjusted correctly. With the original firmware I've got similar wireless performance in short distances. But when I went to another room, the link just breaks: the router does not receives the ACK from the client and kicks out it from the network, shown in the log messages from hostapd.
Using the original firmware this does not happen. That makes me think that the problem is related to the router's sensitivity (when listening the clients) because the AirPort utility shows good power (when talking to the clients) at the distance. I don't know how to adjust the sensitivity or if that is even possible: the only thing that came to my mind was the calibration board files. Maybe the sensitivity is adjusted in the board files.
I'm not sure at all of anything. @chunkeey what do you think?
Also: @anders does your router shows similar behavior? Can you upload some screenshots of LuCI -> Network -> Wireless?
If you do, please post only the relevant parts, leaving out any blank background.
I had similar 5GHz issues with both the February 1 snapshot I used before as well as the February 6 snapshot I'm currently using. If I interpret the git log correctly the wireless firmware upgrade that was merged on February 4 so. I don't think there is much point in trying the old one.
Please don't read too much into the reported RX rates values, especially when the connection is idle. Instead measure the throughput with iperf(3)/netperf and the likes .
Oh, there's something completely different happening here. You see, Qualcomm is supplying a library of boardDatas for their various reference designs. And this whole library ends up in the same directory since the developers are not deleting the files (because it might break something?).
That's why you have to pick the right one from the firmware directory. And it's not a trivial task since they are all binaries.
If you think you need to update the ipq-wifi package for the EA6350v3, then please do. It's not as much of a problem as you might think 
.
Yes it's showing the same behavior and I have also run som iperf3 benchmarks to get the real throughput values. It's strange that the 5GHz values seems to get worse over time...
For 2.4GHz I get a steady throughput of around 105-110 Mbps in both directions. For 5GHz I can hardly connect any more and when I do throughput is close to 0 Mbps, have tried many different channel and bandwidth settings.
(On my other access point I can get up to 500Mbps actual throughput on 5GHz.)
I understand, @chunkeey. But I thought about it before doing this "test" and I copied a large file (22 GiB, single file) to mi NAS which is directly attached to the USB port.
With the 5 GHz connection it was barely reaching the 1.5 MB/s, switched to 2.4 GHz with a 300 Mbps link and it went to 21 MB/s steady (the speed of a 5400 RPM HDD).
Yes, this sounds pretty much like the early days of the RT-AC58U. Well, I'll be waiting for the ipq-wifi update then.
@stangri
Hello,I'm the maintainer for the luci-app-advanced-reboot and with the tremendous help of @imi2003 and very helpful information from @hnyman I've added support for EA6350v3 to the package.
Before I send a pull request and the new code goes live at official OpenWrt repo, could you please test the version 37 of luci-app-advanced-reboot currently available at my repo: https://stangri.github.io/openwrt-repo/ 6
I welcome feedback before I send PR.
Has anyone had a chance to confirm this is working on their router.
@stangri needs feedback before he sends the PR
If I'm barely 10cm away from the router I get this throughput:
Which is awesome by the way. But this just makes my thoughts stronger: this is a problem related to sensitivity. I don't know how this works and why the original firmware is giving the same results at way more distance. I tried 3 calibration board with no success at all. By the way, macOS reports the same TX speed as LuCI reports the RX speed so...
I have some extra juicy screenshots:
Those screenshots shows 3 networks: the ones
:5.0GHz and :2.4GHz are the OpenWrt networks. The other one is a cheap WiFi access point that I brought years ago and installed on the 1st floor (I'm on the 2nd floor). Both routers are in the same vertical axis, but in a different horizontal plane. In the plane, I'm about 4.00 m to 5.00 m away from them!(Obviously, I'm farthest away from the cheap yet better router because of the vertical distance, a square rectangle, hypothenuse, and so on)
I'm just clueless.
Hi @NoTengoBattery have you tried using the old board-2.bin file from the previous release? I'm at work at the moment so cant test till i get back home
Hello all, I have this router on stock firmware version 3.1.10.191322
What can I do to be of use to this project, I'd like to be able to use owrt on this router.
I'm tech savvy and handy with a soldering iron if needed to get a serial connection up and running.
My programming skills are limited, however I'm happy to contribute in any meaningful way.
Thanks ahead of time, and thanks for your work and progress.
hi @NoTengoBattery just got home and i've copied over the original board-2.bin file from the original release. 5ghz is a lot better. My dell laptop with a intel 7260 wifi card, actually connects now with good speeds.
I first want to thank @NoTengoBattery and all the other contributors on this effort. Much of what was contributed for support of current Linksys devices has been and will be very valuable in
One thing that I noticed in that work is that the extraction of the MAC address from the devinfo partition seems to be not quite right, as macaddr_add expects a string for its first argument, not a sh-executed result from that string. On the EA8300, there is an error that posts to the console, but not to the logs about this. I don't have an EA6350 V3 on hand so I can't test it, but I believe that the following patch should correct this issue
--- a/target/linux/ipq40xx/base-files/etc/board.d/02_network
+++ b/target/linux/ipq40xx/base-files/etc/board.d/02_network
@@ -64,7 +64,7 @@ ipq40xx_setup_macs()
;;
linksys,ea6350v3)
wan_mac=$(mtd_get_mac_ascii devinfo hw_mac_addr)
- lan_mac=$(macaddr_add $(wan_mac) +1)
+ lan_mac=$(macaddr_add ${wan_mac} 1)
;;
esac
Reference /lib/functions/system.sh
macaddr_add() {
local mac=$1
local val=$2
local oui=${mac%:*:*:*}
local nic=${mac#*:*:*:}
nic=$(printf "%06x" $((0x${nic//:/} + $val & 0xffffff)) | sed 's/^\(.\{2\}\)\(.\{2\}\)\(.\{2\}\)/\1:\2:\3/')
echo $oui:$nic
}
root@OpenWrt:~# wan_mac=11:22:33:44:55:66
root@OpenWrt:~# echo ${wan_mac}
11:22:33:44:55:66
root@OpenWrt:~# echo $(wan_mac)
-ash: wan_mac: not found
I want to hear (technically speaking, read) more about this! Please let us know, if you can, what did you do and what results do you get (wold be amazing if you can show both!).
Also, soon I will upload an archive with a total of 4 calibration board files if somebody wants to help me testing in this journey to get decent WiFI.
I don't have an EA6350 V3 on hand so I can't test it, but I believe that the following patch should correct this issue
Blame on me! I did that part! Oddly enough, it dones not crash the interface or something weird: it just copies the WAN MAC into the LAN Switch MAC. Thank you for observing this bug, My idea was to echo that value in a sub shell as I didn't knew how ash differ from bash. I will send a PR to Upstream soon!
@escalion and I worked hard to make that process easy. You don't need serial console or soldering anything.
You can use the official OpenWrt snapshot builds here or my custom builds here (build that aims to be a full distro for this device with many software installed out of the box).
Please use the "factory" images to flash from the Linksys update webpage.
1 Like
Thank you again for your explanation.
I do have a problem I'm wondering if I could get a little guidance on.
I took the firmware from your custom builds github and uploaded the factory image first.
Then followed up with the sysupgrade, as seemed to be indicated from the new web panel.
I then proceeded to setup my network config for PPPoE. Once applying I was greeted with a message stating the configuration was incorrect, and that I may proceed with the settings if I know they are correct. Naturally since I knew the only changes I made where the PPPoE setting and it's associated username and password I went ahead with the changes.
Now the router will not respond at the 192.168.1.1 address in my browser.
I'm not sure where to go at this point, anyone have any thoughts? Thank you for your time, and sorry to bring up this issue.
To further clarify: I have my DSL modem in bridge mode, and want to use the router to authenticate and dial in.
Results from a ping
C:\Windows\system32>ping -4 192.168.1.1
Pinging 192.168.1.1 with 32 bytes of data:
Request timed out.
Request timed out.
Reply from 192.168.1.5: Destination host unreachable.
Request timed out.
I'm not sure if she is still alive or not. Seems to be so, but hard for me to tell at this point, I may solder up a serial connection if I can find my kit.