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.
I think I understand. Just one thing: please read the large text I wrote if you are using the custom build. It states that LuCI will start in Failsafe mode, you just look at the corner for Administration mode. No need for flashing another firmware.
For reseting the router to factory defaults you can restart the device and press the WPS button while it is booting. I can't help you with PPPoE because I don't use that feature, but you may be kicking a bug!
Here I found some interesting tips for recovering a misconfigured device. Hope to know about your router soon!
OK I got a serial connection going currently and I'm trying to dig through it's output.
Here is the boot log as of now.
https://hastebin.com/uhayijoxum.cs
If you don't mind taking a look and telling me if something sticks out please let me know.
The big issue at the moment is that there is no ethernet connection running so tftp is out as far as flashing the firmware again to get a solid reset. Also as stated previously the LuCI panel is not present.
I can only assume DHCP is not functioning at the moment. I'm still try to read the log and figure this out hehe.
I follow that up with this output from attempting to reset the router manually via serial connection.
oot@(none):/# grep squash /proc/mounts
/dev/root /rom squashfs ro,relatime 0 0
root@(none):/# mount_root
[ 235.879352] mount_root: loading kmods from internal overlay
[ 235.910006] kmodloader: loading kernel modules from //etc/modules-boot.d/*
[ 235.912478] kmodloader: done loading kernel modules from //etc/modules-boot.d/*
[ 237.065885] block: attempting to load /tmp/ubifs_cfg/upper/etc/config/fstab
[ 237.066279] block: extroot: not configured
[ 237.132591] mount_root: rootfs_data:/dev/ubi0_1 is already mounted as /overlay
root@(none):/# umount /overlay && firstboot && reboot now
[ 266.667502] jffs2reset: This will erase all settings and remove any installed packages. Are you sure? [N/y]
y
[ 269.833060] jffs2reset: /dev/ubi0_1 is not mounted
[ 269.833142] ubi0 error: ubi_open_volume.part.0: cannot open device 0, volume 1, error -16
[ 269.836793] jffs2reset: /dev/ubi0_1 will be erased on next mount
[ 269.845091] jffs2reset: writing /dev/ubi0_1 failed: Bad file descriptor
I'm unsure if flashing the other image corrupted the file system.
OK. I don't see a corruption problem, but I don't know what is jffs2 doing in your system!
There is a high chance that you are facing a bug that @jeff reported. Probably the MAC address of the LAN is preventing you from using your PPPoE.
If you look at the /etc/config/network file you will see that the MAC address of LAN is "+1". Obviously this is a bug. I've already fixed the bug, but flashing the fixed image will break the device unless you flash the image with a factory reset.
I recommend you reverting back to stock, wait for the image I built with the fix, flash that image from stock and then trying again.
I'd happily do that, however flashing to stock seems to be a problem as well, I have the stock image, however in uboot the tftp server dies endlessly.
Also thank you so very much for your support on this.
EDIT: The MAC address isn't set in network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fde1:de0e:e88e::/48'
config interface 'lan'
option type 'bridge'
option ifname 'eth0'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config device 'lan_dev'
I'd like to make a confession in regards to a mistake I made 
I set the bridged Lan connection to PPPoE instead of the WAN connection and borked the entire setup.
The rescue was to reset the settings of the router via /sbin/jffs2reset after fully booting. This fixed me up entirely. I'm sorry for the interruption that was caused by my over site.
Thank you again immensely for all of your help here.
2 Likes
It's easily done I'm afraid! Glad you got it sorted.
This goes for all the people involved that may want to know about this.
(Problems with DNS (web pages not loading but able to ping ip addresses)? uci set dhcp.@dnsmasq[].noresolv='1' will fix it. I will amend that in the following release next week)
I JUST HIT THE NAIL with this device! Oh, I am so satisfied right now. I knew it was the calibration board! It's just amazing.
I think all of you want to give a try to my latest "release", that release will have the amazing wireless performance of stock (or arguably better).
@escalion @Afraidium @jeff @imi2003 @anders @elitedz you may be interested.
For you, @chunkeey, may I ask you if we get positive results from other people than me... can you do the commit? I don't want to make the pull request and bla bla... but I'll do if you say no. Just let me know.
Note: due to a simple yet annoying bug and it's respective bug fix (which is not in Upstream yet), you will likely end up with an inaccessible device after the upgrade. Please, do a factory reset. I will not answer questions which are solved in the "Release Notes".
1 Like
Took me a while to find it, but by "release notes", you're referring to
Yes?
Also there are some "challenges" with failsafe, OpenSSH, and removing dropbear (which I routinely do) -- One approach at https://github.com/openwrt/openwrt/pull/865 Yes, on my long list to "modularize" this as per project request.
Yes please, I would like you(or someone with a EA6350v3) to have the honors and post the board-linksys_ea6350v3.bin update patch. Thanks to the responses in this thread, you don't have to write
that much. just add @anders and @imi2003 testament:
From before:
And after:
and add a link to this thread (Bug-Link: tag) and be done with it.
SSH works and I decided it to be like that: prevent root login and use a dummy user with sudo. Not a big deal, the user is created automatically, added to sudoers automatically and pretty much that...
I understand the problem now. I will add Dropbear and disable it. It should work without pain in failsafe mode with the benefits of OpenSSH in normal mode.