-
-
Notifications
You must be signed in to change notification settings - Fork 13
Open
Description
txnative created an issue 2024-12-29
Tested on f9k, e3200, wndr3400v2.
- cleared nvram using both methods using gui, 30-30-30, press +hold reset button on f9k for 30 sesconds.
- the issues in mainly using the configured 5GHz wireless ethernet bridge → 2.4GHz AP mode.
- after a crash the reboot reboots on wndr3400v2, e3200 and will return with working configuration.
- after f9k crashes and reboots, the 5GHz doesn’t return on reboot, an additional reboot needs to follow.
- tested on speed.cloudfare.com on these models and within 15 seoncds a reboot will occur.
- traffic doesn’t seem to be an issue until watching 1080 resolution youtube videos or using the cloudflare test site mention.
- I am the only one on these models during these reboots, using a connected pc or connected to pc wireless adapter.
- memory/ram are within good for this particular config.
Used / Total RAM 16.28 MB / 60.14 MB (27.07%)
Used / Total NVRAM 26.12 KB / 32.00 KB (81.62%)
- Now if I choose to use 2.4GHz wireless ethernet bridge + 5GHz AP mode, this config is more stable.
- This issue also occurs on wireless client mode 5GHz wireless client mode, 2.4GHz AP.
- typically nothing shouldn’t need to be setup differenlty in “advanced-wireless” but if done it may help but it doesn’t keep it stable as a reboot may occur at some time later depending on what a user is doing online.
I did try to use old nvram_set from mdmower init.c with the same results.
Best regards
Comments (18)
pedro repo owner
changed status to [new](https://bitbucket.org/pedro311/freshtomato-mips/issues?status=new)
2024-12-30
pedro repo owner
We only have a few commits between 2024.4 and 2024.5 in the MIPS branch, so the only explanation for the issue in this case could be dnsmasq.
Could you revert dnsmasq to the one in 2024.4 (dnsmasq: update to [f006be7](https://bitbucket.org/pedro311/freshtomato-mips/commits/f006be7) (2024.10.04) snapshot) or at least to “dnsmasq: update to [6c9bc01](https://bitbucket.org/pedro311/freshtomato-mips/commits/6c9bc01) (2024-12-02) snapshot“ and compile/test such image?
2024-12-30
pedro repo owner
So, for example:
git revert --no-commit [93b70d2](https://bitbucket.org/pedro311/freshtomato-mips/commits/93b70d2d7de16eef3060a25b7427f1f06f0bee4b)
git revert --no-commit [fab6fa6](https://bitbucket.org/pedro311/freshtomato-mips/commits/fab6fa6682e1f23cdfff07fcf18f56cfcdf74fd8)
git revert --no-commit [8a9d542](https://bitbucket.org/pedro311/freshtomato-mips/commits/8a9d542df49ea5fefbf9d0a72dbc1e3dbbe1e6d9)
git revert --no-commit [3ca3187](https://bitbucket.org/pedro311/freshtomato-mips/commits/3ca31873412658e6b6a25b838f802e202cba17b3)
make /…./
2024-12-30
txnative reporter
Okay I can revert the current dnsmasq to the later as you had mentioned, but could this also be a usb driver conflict to the reverse patch for 5ghz wifi as well?
2024-12-30
pedro repo owner
There were no (major changes) in MIPS branch since last release (maybe only 12+ commits?), so only dnsmasq is yhe cause, IMO.
2024-12-30
txnative reporter
Right, and it may not be related to dnsmasq since I tested a different model F7D4302 using RT-N branch and not effected but TBH it has been a troubling issue since before you had taken command. These models losing 5GHz has been in threads from the past up till now, except more so on the F9K as it takes an additional reboot to recover the 5GHz the other models I had been testing will reboot and recover but it is an on going issue.
In the past we assumed it had something to do with nvram size on E3200 or WNDR3400v2/v3 it was changed but it really made no difference as it something becomes unstable during 5GHz usage more so using 5GHz wireless ethernet bridge config..
We know it is setup on the usb uhci and we can see it in the dmesg part of the log on a clean boot without any configuration done, and if maybe using a slower Mbit/s instead of EHCI that supports higher Mbit/s but even though it is selecting EHCI on for these models that are using the reverse patch, theory of course using the wl_high reverse patch?
Edited A dnsmasq revert doesn’t seem plausable it works fine for RT-N Branch model F7D4302 but not off topic. Looking at the anon.groov.pl builds for these models we can see no one using newer builds for models built with the wl_high, I am certain users are seeing it crashing, rebooting as well but not so much in eariler builds but it will crash at some point.
2024-12-30
pedro repo owner
So we’re talking about issue in 2024.5 which is not in 2024.4 or in OLDER release? It’s important.
2024-12-31
txnative reporter
Yes, the crash rebooting has been around before the 2024 builds on the RT-N WL High models, it is I can trigger a crash easy using [speed.cloudflare.com](http://speed.cloudflare.com/) while in 5GHz ethernet bridge mode with the 2.4GHz AP mode it can crash since both eth1 and eth2 are working together.
The other opposite configuration works great no reboots and so it mainly is on the reverse patch for the usbap IMO.
2024-12-31
txnative reporter
Something before I forget, in the src-rt/shared/bcm_rpc.c on line:1033 would there be a way to obtain logs of these reboot rpc errors? Or is this a wild goose chase?
2024-12-31
pedro repo owner
I’ve no idea, but even if it’s possible, you still don’t have there error number or anything describing it.
2025-01-03
txnative reporter
It was just a suggestion to figureing out if bcm_rpc is part of the problem?
I know you are busy but at least it is mentioned that an issue does exist on wl high models, we can close this issue with no fix for it.
2025-01-03
pedro repo owner
Maybe @M_ars will be more helpful here?
2025-01-07
txnative reporter
If he has reading from the messages and logs sent then he is aware, as I now your work flow is constant for FreshTomato sources, I can still troublshoot to try and narrow down something useful and provide it on my side but where should I keep in contact?
Regards.
2025-01-07
M_ars
txnative, maybe you can try to find the last working and first NOT-working freshtomato version. If this area is known it would be a first step. Currently no idea what it could be. BR
2025-01-08
txnative reporter
This issue has been around ever since the wl high was ported back around 2012 then after with reports on the linksys e3200, e2500 and on up to 2023 reports on the belkin and netgear wndr3400v2/v3 losing 5Ghz. There may have not ever been a good build that lost 5GHz or crash/rebooted using the reverse patch.
If users had a very light bandwidth usage it should be stable enough but if needs exceeded more than 8 Mbit/s any of these models would crash/reboot.
2025-01-08
txnative reporter
For now it should at least be in the wiki to avoid using 5GHz upper/lower 40Mhz side band, but instead use 20MHz followed by selecting a 5GHz upper or lower band channel to avoid frequent reboots or losing 5Ghz if someone is using the Belkin at least if or until the problem is resolved.
Is this okay?
2025-01-22
M_ars
Yes, good idea to add a note to the FT wiki. Please go ahead :)
5 days ago
txnative reporter
Okay. but it should be in the forum for users to find through the search.
5 days ago
Metadata
Metadata
Assignees
Labels
No labels