Well in the end the Sonoff IoT device turns out that have to be deleted from the ewelink app while still using the old router connected, that enable the device to reconfigure to use another router and be setup from zero... crazy but true...
1 Like
mag2352
2170
I seemed to figure out the issue with the ESP devices on my network. For some reason, they really just don’t like any other channel but channel 1. I had set my APs to 1,6,11 to not be overlapping, but I set my APs all the channel 1, then 6, and then 11. On channel 1, they connect immediately without issue. On the other channels, they don’t acknowledge authentication and get repeatedly kicked off the network. I will try with AX on as well, since I had them on N, but I’m glad I found a working solution. I don’t really care about the throughput of my 2.4ghz network, so interference is a non issue (if this is the only solution, I’ll tune power levels appropriately, or outright disable radios on some of the APs).
Now to figure out how to handle the roaming handoff issue… it’s starting to get really annoying.
1 Like
qosmio
2171
So pretty much as you found out if you want 802.11s/mesh your only bet is 11.4. I strictly run that on my own 7 node setup and it's been pretty stable. FT/Handoff also work well, and I haven't noticed any connection drops during handoffs. Client implementation matters too, so nothing you can do router side if the client is the one ultimately making the switch.
If you're OK living without 802.11s then you can try out FW 12.2. Some users have reported better luck with that version for their setups. 12.5 has been pretty mixed as far offloaded WiFi goes
You could, but that commit assumes single partition setups. If you wanted to expand the user partition you'd need to choose which of the 2 user partitions to expand. I rather have one giant secondary user partition that's accessible to both primary and alternate booted instance.
2 Likes
mag2352
2172
In my case, I’m not running mesh. I’m using 5 nodes, all wired backhaul. Every time the client (iPhone) chooses to move between APs, the connection interruption happens. This problem wasn’t happening prior to swapping all of my routers to the MX4300. If I use LuCi and disconnect the client and hence force it to FT to another AP, it has the connection drop most of the time (sometimes it works fine). Of note, it only happens for connection that are active before roaming occurs (e.g. an online game or VoIP call). Once the roaming happens, the connection on that call will stop for around 5 seconds, then continue as expected. I’ve tried setting the APs to the same channel just to test if it makes any difference. In your setup, do you make any changes that isn’t present in arix’s builds (I figure that you are running your own build and wouldn’t be too familiar with arix’s one)? Maybe IPv6 being disabled, etc.
All of that aside, I very much appreciate your work on getting these routers functional, amazing value for the price (thanks to you and others). Getting near gigabit transfers over WiFi with ease was a dream for me a few years ago (without breaking the bank).
@arix @qosmio sorry to bother... does the way feeds works changed ? there is no more https://downloads.openwrt.org/snapshots/targets/qualcommax/ipq807x/packages/Packages.gz and now the apps have .apk extension... how can I update feeds ??
Answering myself, openwrt moved from opkg to Alpine's APK in snapshot:
1 Like
I am running https://github.com/arix00/openwrt-mx4300/releases/tag/qualcommax-nss-7a9d4c3 and the router goes through random reboots. There is no specific pattern that I can see. I searched for "reboot" in this thread but did not find any mention of this issue. I have seen freezes too but that's a separate issue.
The router reboots abruptly and "uptime" reflects that and all the clients get disconnected.
Is there a way to know if there has been a kernel panic or if the reboot happened due to some hardware fault?
How do I troubleshoot this?
I am using build from ddwrt and facing same issue as well.
The memory usage keeps increasing and finally system will crash & reboot itself. The issue happens only when wireless is turn on.
Idk is that a memory leak or driver issue.
private
2177
Could someone drop a amazon link to a jumper wire that works with the serial pins on the MX4300? I've bought 3 uart connectors and the connectors were all too big. I have been searching to find the correct thing but I quite frankly have no clue what i'm doing.
I don't see memory increasing with openwrt. This seems to be wifi related to me but I have no way of proving it.
I am back to using Openwrt after using dd-wrt for many years and I am researching if there are any facilities to capture kernel panics. Will look into hooking serial port.
For now, I have enabled multicast to unicast on all Wi-Fi interfaces and monitoring if that makes any difference.
This is pretty much the last issue I have with this build. It took many trial and errors to get the correct Wi-Fi config so that all my devices connect.
mag2352
2179
Do you know if the transition issue persists on FOSS (no nss builds)? I might try the FOSS build to see if the issue is present there. I’m assuming just flashing and wiping the config is sufficient to switch between the two.
I have not used it personally ( was researching the serial connection) and from a reddit thread, someone recommended this: https://a.co/d/hw6Xo3r
reddit thread: https://www.reddit.com/r/DDWRT/comments/1fjvtt9/linksys_mx4300_reset/
No luck. I just had my router reboot after setting multicast to unicast on all Wi-Fi interfaces. Not sure how this can be troubleshooted. Anybody else seeing random reboots?
I can't keep up; what's preventing the LN1301 builds from being official? I'm running stock on my 3-node mesh, but I have a spare unit I can use to test if there's something I can contribute to the project!
PalasX
2183
Also feeling a little lost on that topic. i'd been using the builds here:
but i cant even find notes on the last build "dab02bc" other than the github changes.
Is this no longer the "suggested" build?
I've been using the FOSS builds here for several weeks now. (There are also NSS builds.)
From what I've gathered, the "block" for getting MX4300 officially added to OpenWrt is a complaint that (allegedly) too much is changed in the code and there's a worry about other devices being negatively affected. I can see that, but I've also perused the PR and it looks sound... just needs testing on devices other than MX4300?
(Just a disclaimer, I am not OpenWRT-fanboy on Github despite our name similarity. 
)
1 Like
I am confirming a week later that this 100% fixed the problem I was having with my Pixel 6 Pro bouncing around SSIDs not able to find the internet. Now it connects immediately to the correct SSID, finds the internet, and stays connected.
This seems to be a known problem on IPQ8xxx series, beyond just our router... is this really the only "fix" or is there a problem in code that can be resolved?
From what I understand the multicast issue is well known on ipq807x devices.
1 Like
PalasX
2186
Any major difference in the builds from TestUser7 and Arix00 ??
1 Like
I will say that the crux is the kernel patch I wrote to dynamically patch the bootargs at boot time.
We can replace the patch with bootstrapping. There is already a script I posted above that can do this. We just need someone to refine it, put it in the right place, and test it.
2 Likes
private
2188
Thank you for your suggestion. I ended up buying a kit and creating my own jumper wires. It was surprisingly easier than I thought it would be. If anyone is interested, the connection is JST PH 6 pin.
1 Like
