I've switched to WPA2-PSK AES but this is what I get when the phone is just idling on 2 meters from the router with great signal level.
And most of the time it simply shows there is no Internet connection. The model is 2 years old and fully support WPA3 with my R7800 and never had a problem over 2.4GHz band over 3 walls and big distance.
I've tried all the builds starting with Dangowrt Release v0.6.5, next updating to the 22.03 snapshot, and finally with latest master with WED enabled/disabled. I've tried even without protection at all. Retstarted the phone and the router several times. No difference.
@quarky @Ansuel
Just for the record about the WAN/LAN performance drop with 100Mbps client connected to a LAN port.
I've tried all the speed tests with Belkin RT3200 with all the builds starting with Dangowrt Release v0.6.5, next updating to the 22.03 snapshot, and finally with latest master (kernel 5.15). The issue is repeatable.
Additionally I've tried all tests with old TP-Link WDR4300 (running current master) - the above issue with WAN/LAN slowdown is present on WDR4300 too.
Please do not do this. There are lots of reasons
- It is not legal (duh!)
- It fosters a regulatory climate where the FCC (in the US) will revive rules that regulate third-party firmware. (There was a furious effort by the OpenWrt team about
fiveseven years ago to abort pending rules that would have made it harder for us. We were successful that time. Let's not find out if we can do it a second time.) - Increasing the power of the access point will, indeed make its signal travel farther, but at the cost of more interference for neighbors, but...
- This technique doesn't even work that well. Your laptop might be able to "hear" the signal farther away, but it will not have increased power to send its responses back, so they'll be dropped, and you won't work appreciably better.
Thanks for listening.
14 Likes
Please, guide me in upgrading my belkin firmware from openwrt snapshot r18660-5bd926efa9
I am stucked in that snapshot for several months.
It has been working well, but I think it is time to upgrade.
The attended sysupgrade does not work due to changes in iptables from 4 to 6.
I need to upgrade but am afraid that all my configuration would not work after that.
I have serveral networks working with VLANs, and the corresponding wifis and firewall rules to isolate them, ppeo wan with the corresponding config, wireguard VPNs and serveral other config I can't even remember how I configured it.
I suppose I should make a backup of the config first using generate archive.
Should I save some mtdblock too?
And what to do after that? Is there some current stable release I should flash?
If you think it is more appropiate, I can open a separate thread with this in order to not contaminate this one.
Though this might to be too important, it annoys me every time I read this: These rules were suggested by the European Commission and only because "open minds" in Europe tend to believe that something as bad as that has to come from the US it was commonly referred to as the "FCC lockdown" -- it should have rather been called the "ETSI lockdown" or "RED lockdown" (as it was this EU commission's Radio Emissions Directive indirectly suggesting mandatory secure boot). The FCC was merely copying ETSI's suggestion, so it's kinda strange to blame it on them...
5 Likes
Thanks for the clarification about the source of that regulatory pressure. I do know that a lot of people (15) spent a lot of time (several days each) preparing a response to the FCC proposal. (Finally found a link to the document from 2015.)
I just don't want to do it again... Thanks.
2 Likes
Hey, just received a Belkin rt3200 from ebay, unfortunatelly dead (no leds, nothing on the ports). After connecting the serial i get:
F0: 102B 0000
F6: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0000 0041 [0000]
G0: 0190 0000
T0: 0000 0290 [000F]
Jump to BL
UNIVPLL_CON0 = 0xFE000000!!!
mt_pll_init: Set pll frequency for 25M crystal
[PMIC_WRAP]wrap_init pass,the return value=0.
[pmic_init] Preloader Start..................
[pmic_init] MT6380 CHIP Code, reg_val = 0, 1:E2 0:E3
[pmic_init] Done...................
Chip part number:7622B
MT7622 Version: 1.2.8, (iPA)
SSC OFF
mt_pll_post_init: mt_get_cpu_freq = 1350000Khz
mt_pll_post_init: mt_get_mem_freq = 1600000Khz
mt_pll_post_init: mt_get_bus_freq = 1119920Khz
[PLFM] Init I2C: OK(0)
[BLDR] Build Time: 20200522-165358
==== Dump RGU Reg ========
RGU MODE: 4D
RGU LENGTH: FFE0
RGU STA: 0
RGU INTERVAL: FFF
RGU SWSYSRST: 8000
==== Dump RGU Reg End ====
RGU: g_rgu_satus:0
mtk_wdt_mode_config mode value=10, tmp:22000010
PL P ON
WDT does not trigger reboot
WDT NONRST=0x20000000
WDT IRQ_EN=0x340003
RGU mtk_wdt_init:MTK_WDT_DEBUG_CTL(590200F3)
[EMI] MDL number = 2
[EMI] DRAMC calibration start
[EMI] DRAMC calibration end
[EMI]rank size auto detect
[EMI]detect rank0 size error!!
<ASSERT> emi.c:line 1909 0
PL fatal error...
Is there anything i can do? Any way to get into debug mode or suggestions on reprogramming the memory?
So this is the stock Preloader, hence this device is still with stock firmware and never had OpenWrt installed on it.
Probably the DRAM chip is broken, which could be a result of extreme heat or radiation, broken power supply, ... or maybe it even came like this from the factory (QA should catch that though before it leaves the factory).
If it still got warranty I'd ask for having it replaced, as this is quite clearly a hardware defect. Without warranty it's of course in theory possible to swap the DRAM chip, but BGA SMD soldering is tricky and you'd need to find this exact chip as replacement...
3 Likes
This is my setup for 5Ghz radio. Idk why but the signal strength is not stable, the wifi range gets too low suddenly and comes back to normal after sometime. Anyway to fix it?
did you try to set the channel on "default" ? and do you have the same problem if you set AC mode (not AX) ?
And I just don't want to imagine the consequences of not being able to control key settings of my home network during the 2 year pandemic lockdown if my router had the stock firmware on it instead of the freedom and security granted by OpenWRT firmware.
Do a Channel Analysis under LUCI -> Status and check 5GHz maybe neighbours?
Is it possible to disable the boot to recovery whenever a kernel panic happens? I do love the fact logs are kept after a crash, so they can be investigated. But I would like the router to simply boot back to its regular image. The router acts as a VPN server offsite, so it not coming back online after a crash is a deal-breaker for me.
See hnymans script Belkin RT3200/Linksys E8450 WiFi AX discussion - #1775 by hnyman
Yep, I wrote that in March.
1 Like
Maybe make it the default for the router to always reboot to the regular image?
- Experienced users will have an easier time diving into the console to change the variable if they so desire their device to reboot into recovery after crashing.
- Even if it reboots into the regular image, the logs should still be saved, correct? So a user is able to inspect those logs, regardless of whether the router booted into recovery or not.
The only real advantage I can see with the current default behavior, is that it's very clear that something has happened and the router rebooted. However, this functionality doesn't exist for any OpenWRT router as far as I am aware, so the current default behavior deviates from how OpenWRT operates on any other router.
@daniel Any idea of how I should proceed regarding a second mt76x2u device crashing iwinfo and therefore luci? Would like to get my E8450 up and running, as I've currently gone back to my R7800 due to this issue.
I have no idea (and also don't have mt76x2u at hand for testing), but strange that it happens on this hardware and not on the R7800.
What do you see if you call iwinfo in the console?
Can you maybe compile it with debugging symbols and run it with gdb?
@davendesai Is this the same issue you are seeing?
When I ssh to my RT3200 and do 'iwinfo wlan1 scan', all of the wireless devices on that interface (5GHz) are disconnected.
When I run luci -> Channel Analysis -> 5GHz, it does the same thing. If I run from one of those wireless devices, luci appears to die; if I run from a wired device, it sees the network scans ok (but again, all wireless connections are broken).
1 Like
@davendesai I'd ask lorenzo at linux-wireless on the kernel mailing list. Last time I did, he and another developer found some nasty IOMMU bugs. Probably not the case here but still worth doing so.