Hi, I think I bricked my router. To get more info I attached a serial connector. Using serial I cannot select another option in uboot, it selects by default option 3 and does not wait for input. Is there anyway to change the uboot setting? The router itself is in a bootloop ending in a kernel panic and will not boot normally.
Also it does not reload stock firmware using miwifi.bin on FAT32 usb key
Hold down key 4 while powering the device and then execute:
setenv uart_en 1
saveenv
reset
This will enable uart output and gives you more time to choose one of the options...
You could also hold down key 1 to boot a initram image from tftp and then flash openwrt with sysupgrade from withing the initram image.
Checkout this site if you want to see which options available...
That's what I did with my other router. Upon your help I checked the connectors, soldering, cables, even used two different serial adapters all with no access to enter "4" for uboot. Can it be that uboot's now locked by default in new firmware?
Sorry, I did make an error, mixed wires on the uart connection. Can select option 4 now.
It took me only 1,5 days to find the miswiring... Thanks for the help!
Thanks!
I did some statics leases in Luci without ip and worked.
Hello after months of using Xiaomi mir3g (and weekly upgrading to last snapshot, now i'im on r7490) still having random reboots. finally i managed to save at least the syslog (putting it temporary on /etc/syslog.log) after 2 reboots happened this is the result
Mon Jul 16 22:01:38 2018 kern.alert kernel: [27285.812994] CPU 3 Unable to handle kernel paging request at virtual address 07403fe0, epc == 800f8524, ra == 800f8684
Mon Jul 16 22:01:38 2018 kern.warn kernel: [27285.823608] Oops[#1]:
Mon Jul 16 22:01:38 2018 kern.warn kernel: [27285.825874] CPU: 3 PID: 2829 Comm: miniupnpd Not tainted 4.14.54 #0
Mon Jul 16 22:01:41 2018 user.notice dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
yes, theres is a little of garbage characters probably due to the crash during write
Wed Jul 18 09:38:01 2018 kern.alert kernel: [ 9389.367879] CPU 0 Unable to handle kernel paging request at virtual address 0000802f, epc == 8f091ae0, ra == 8f091994
Wed Jul 18 09:38:01 2018 kern.warn kernel: [ 9389.378491] Oops[#1]:
Wed Jul 18 09:38:01 2018 kern.warn kernel: [ 9389.380759] CPU: 0 PID: 4870 Comm: kworker/0:0 Not tainted 4.14.54 #0
Wed Jul 18 09:38:01 2018 kern.warn kernel: [ 9389.387213] Workqueue: events_long nf_ct_kill_acct [nf_conntrack]
Wed Jul 18 09:38:04 2018 user.notice dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
@nbd do you think is something about the nand bad blocks?
ps. just consider dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses! as the first log text got after a reboot
Hi there, I've build a new Image via the ImageBuilder (from here: https://downloads.lede-project.org/snapshots/targets/ramips/mt7621/) and encountered something at the end that the partition size for the rootfs was not specified:
[rootfs]
mode=ubi
vol_id=0
vol_type=dynamic
vol_name=rootfs
image=/home/fork/openwrt-imagebuilder-ramips-mt7621.Linux-x86_64/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/root.squashfs
[rootfs_data]
mode=ubi
vol_id=1
vol_type=dynamic
vol_name=rootfs_data
vol_size=1MiB
vol_flags=autoresize
ubinize: volume size was not specified in section "rootfs", assume minimum to fit image "/home/fork/openwrt-imagebuilder-ramips-mt7621.Linux-x86_64/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/root.squashfs"2524458 bytes (2.4 MiB)
Is this a wanted thing or might it be that ubi generates block errors because of that?
I'm trying for a few month with this router and I'm sure the wifi performance of LEDE is not as good as the stock firmware or padovan.
Connecting time to wifi takes about 10-15 sec on LEDE and 2-3 on the others.
Also wifi signal is weaker on LEDE.
Any idea about this issue?
Maybe the driver is different?
https://downloads.openwrt.org/releases/18.06.0-rc2/targets/ramips/mt7621/
I am currently on RC2. It works good until now.
But I have one Problem:When I change the transmit power on 2,4Ghz nothing changes. It always shows 0dB Power but according to my Wireless Strength Phone app it always radiates with full power.
on 5Ghz a change of transmit power works.
Jep can confirm that on
OpenWrt SNAPSHOT r6880-aadca03 / LuCI Master (git-18.133.37847-2f0f456)
Hi,
I'm facing some random reboot, then I've manage to get a stack trace from serial port :
[59591.008888] ------------[ cut here ]------------
[59591.013539] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:320 dev_watchdog+0x1ac/0x324
[59591.021799] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
[59591.028731] Modules linked in: pppoe ppp_async pppox ppp_generic nf_conntrack_ipv6 mt76x2e mt7603e mt76 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables crc_ccitt compat ledtrig_usbport ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables tun leds_gpio xhci_mtk xhci_plat_hcd xhci_pci xhci_hcd gpio_button_hotplug usbcore nls_base usb_common
[59591.097128] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.53 #0
[59591.103106] Stack : 00000000 00000000 00000000 00000000 805c7ad2 00000034 00000000 00000000
[59591.111442] 8055ed14 8055e8a7 804ed8cc 00000000 00000000 00000001 8fc09d68 1cc282d5
[59591.119774] 00000000 00000000 805c0000 00007310 00000000 00000183 00000008 00000000
[59591.128104] 00000000 80560000 00017b68 00000000 00000000 00000000 80580000 8035b988
[59591.136434] 00000009 00000140 00000000 8ffaf040 00000003 80285c70 01804017 01804057
[59591.144766] ...
[59591.147201] Call Trace:
[59591.149659] [<80010598>] show_stack+0x58/0x100
[59591.154092] [<8043412c>] dump_stack+0x9c/0xe0
[59591.158430] [<8002e328>] __warn+0xe0/0x114
[59591.162507] [<8002e38c>] warn_slowpath_fmt+0x30/0x3c
[59591.167451] [<8035b988>] dev_watchdog+0x1ac/0x324
[59591.172149] [<80086054>] call_timer_fn.isra.3+0x24/0x84
[59591.177348] [<8008626c>] run_timer_softirq+0x1b8/0x244
[59591.182475] [<804512a8>] __do_softirq+0x128/0x2ec
[59591.187162] [<80032a30>] irq_exit+0x98/0xcc
[59591.191345] [<8023a1ec>] plat_irq_dispatch+0xfc/0x138
[59591.196372] [<8000b5e8>] except_vec_vi_end+0xb8/0xc4
[59591.201313] [<8000cfb0>] r4k_wait_irqoff+0x1c/0x24
[59591.206104] [<8006630c>] do_idle+0xe4/0x168
[59591.210270] [<80066588>] cpu_startup_entry+0x24/0x2c
[59591.215215] [<80585bf0>] start_kernel+0x484/0x4a4
[59591.220038] ---[ end trace 02be6926695082d4 ]---
[59591.224684] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
[59591.230919] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000067
[59591.236922] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=0eca0000, max=0, ctx=2745, dtx=2725, fdx=2716, next=2745
[59591.247792] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=0de40000, max=0, calc=1838, drx=1840
[59591.651909] mtk_soc_eth 1e100000.ethernet: 0x100 = 0x5f60000c, 0x10c = 0x80818
[59591.664949] mtk_soc_eth 1e100000.ethernet: PPE started
[59973.008426] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
[59973.014614] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000067
[59973.020628] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=0dc50000, max=0, ctx=3072, dtx=0, fdx=0, next=3072
[59973.030992] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=0eb70000, max=0, calc=730, drx=731
[59973.450868] mtk_soc_eth 1e100000.ethernet: 0x100 = 0x5f60000c, 0x10c = 0x80818
[59973.464110] mtk_soc_eth 1e100000.ethernet: PPE started
[60583.007720] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
[60583.013899] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000067
[60583.019936] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=0d1c0000, max=0, ctx=3072, dtx=0, fdx=0, next=3072
[60583.030317] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=0d270000, max=0, calc=898, drx=899
[60583.450327] mtk_soc_eth 1e100000.ethernet: 0x100 = 0x5f60000c, 0x10c = 0x80818
[60583.463536] mtk_soc_eth 1e100000.ethernet: PPE started
[61483.006662] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
[61483.012841] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000067
[61483.018857] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=0ef70000, max=0, ctx=3072, dtx=0, fdx=0, next=3072
[61483.029226] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=0dfb0000, max=0, calc=969, drx=970
[61483.449773] mtk_soc_eth 1e100000.ethernet: 0x100 = 0x5f60000c, 0x10c = 0x80818
[61483.463163] mtk_soc_eth 1e100000.ethernet: PPE started
I've restarted the router by serial console as It wasn't completely hang.
What is concerned about this stack ???
Do you use snapshot from before or after this commit?
Hi Jpol,
my snapshot is an "ubi patition tweaked" by Tanonn, so it's clearly before the commit you mentioned.
OpenWrt SNAPSHOT r7452-7e82418372
Just upgraded from RC1 to 18.06.0-rc2, it breaks the VLAN functionality on the GUI. If you go to Network > Switch > Add a VLAN, nothing happens. Reverted to RC1 in the meantime.
I'm using RC2 and after arround 57 hours of uptime without problems, I cannot access luci anymore, getting the following error message instead:
Unable to launch the requested CGI program:
/www/cgi-bin/luci: Exec format error
Routing and radio continues working fine and I am able to connect to the router with ssh.
I believe mt7603en has hardware issues, that software can not resolve. avoid MT7603 for 2.4G is the only way out.
I'm considering buying this router... does Wi-Fi work properly, or is it as bad as some of the people posting here seem to put it?
The 5GHz Wifi works well, the 2.4GHz has some problems.
I had three of these set up; one as a main router exporting LAN and guest (VLAN) networks and two as WAPs.
Because the MT76 driver doesn't yet support adjusting the transmit power on the (2.4GHz) MT7603EN i had it disabled on the main and second WAP and just had a centrally-located WAP blasting away at full power.
The WAP with 2.4GHz enabled would lock up completely, requiring the power to be pulled. This would happen randomly anywhere from a couple of minutes to a few days after boot.
The other two routers, which only have 5GHz enabled, don't exhibit this problem.
If you don't need 2.4GHz then i'd definitely recommend the MIR3G, i don't think there's a better value router out there. If you do need 2.4GHz then one of these coupled with a second-hand ath9k-supported device will probably still work out cheaper than an alternative router.
Thanks. Using a cheap ath9k device for 2.4GHz is a good call, I have a couple of old TP-Link WR841N units which still work great, could use them until mt76 is sorted out.