On the EB904, Wifi is "external" to the system and a bit of a black box. One can send commands but it won't accept all (documented) commands, and if it does it returns hardly any confirmations or status information. That's probably why LuCI cannot really show its status.
I dabbled with the EB904's Wifi some time ago, so my memory is a bit hazy. But I seem to remember that it doesn't accept all of the commands it should, "country code" being one of them. Also, it seemed like it would accept certain commands only once and never after.
I'm almost sure one could make the LuCI interface show if not the current status then at least the current configuration and allow to modify it, but noone took the time or made the effort to do so yet.
I'm also still interested in future development on this device.
What can we do to solve the issues?
Actually I'm still confused how to come to a working Box with VVDSL support, working (fast) wifi and fast switching speed between wan, lan and wifi.
Thanks @Plonk34, @kovz and @QAuge for their investigation and hard work you already put into this devil device.
I would really love to understand these whole problems with so many different devices.
Unfortunately it seems actually an unrealistic dreaming to get one fully working device with OpenWRT.
Even my recommended BT Hub 5A has still problems with high throughput in wifi and it's a mess to update via serial always the box.
So I don't know if this whole openwrt world is not slowly dieing because we can't get through the important (performance) doors with any device.
I would love to give more to this community than complaining within the last month, but I unfortunately can't really debug and compile whole images. I can just use the chef online builder and put things together and try out. Also soldering is OK, but when it comes to hardware acceleration implementation things in source code I can't help and it's always a hustle to find any solution for such problems instead of using somehow the original source for it...
In the meantime usually people give up and buy a FritzBox and are happy...
The performance is roughly similar between all VRX2xx devices, aside from the decision of enabling FXS ports (and thereby sacrificing a mips core to them) or retaining SMP support. So if your BT Home Hub 5 Type A isn't fast enough, the Easybox 904 xDSL won't be either (given that it has FXS ports, it will be considerably slower (55-60 MBit/s at most) - and its WLAN isn't as good as on the BTHub5 either). With the advent of super vectoring (profile 35b), the days of VRX2xx devices are numbered anyways (GRX3xx/ GRX550/ GRX750, which would support super vectoring, aren't supported by OpenWrt yet).
Unfortunately there is a big problem with drivers. I have found inic driver absolutely spontaneous! There is no datasheet for lantiq IC and most important drivers is closed. Currently I'm trying to bring up LTE version. It looks more simple than xDSL version, but still has a lot of problems. And both versions is outdated due to luck of WiFi ac standard support.
Of course, you can edit the /etc/config/wireless config file directly through the shell.
Somebody would probably have a deeper look why LuCI doesn't pick up on the settings. I reckon it's a minor thing why it currently fails to do so. As for the fact that it doesn't display the current status, I'm afraid that will not happen unless someone reverse engineers what the original firmware uses to do it. I distinctly remember that with the current means I couldn't get any status information no matter what I tried.
I have never used luci no idea if it works.
Did you mean "at the moment '00' and signal power is 0" in luci
Modifie the /etc/config/wireless via SSH and reboot the wifi via: /etc/init.d/rt3883 boot
see the /etc/init.d/rt3883 for single commands.
Some values can be change with the old iwconfig and iwpriv commands. @kovs should correct me, but he background are it based on a very old driver time before using the default nl80211 connection of the linuxkernel.
yes it is normal flash_eraseall do not exist anymore.
use:
and
software flow offloading
brings 88Mbit/s from 94Mbit/s VDSL speed. (no SMP support, i use the FXS ports)
At the moment it is the only solution for VVDSL (up to profile 30a) and Telefon support i can not see that there are somthing change in the next future.
An other thing are these devices second hand are really cheap in Germany.
I do it long time too but i more and more understand why openwrt official support only wifi and ethernet.
Every time when i make an build somthing else does not correct work
At the moment the biggest problem are SQM (using the tc command) in combination with the Wifi driver reboot the devices.
(see here: SQM reboot my Router (Easybox 904xDSL))
@Plonk34 thanks for your information about the rt3884 driver.
What I don't understand is on the device is an Openwrt Backfire previous version originally and it worked quite OK, why is it than so difficult with newer versions?
@all
The kernelversion for the lantiq devices was changed from 4.14.x to 4.19.x
I modifie the pullrequest for it. (It was was simple the most kernelpatches can be leave)
I do only a short test and the Devices works in general.
The bad new is that the wifi driver does not work anymore.
First building is not possible because init_timer(..) function does not exist in 4.19
I replace by setup_timer(..)
I littleit play with it (remove some timer stuff) and i thing the problems is somting with the linux timers.
I thing my code are wrong when i look in some other linux kernel code i found stuff that looks like:
CC [M] /opt/build/openwrt/build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/ralink_inic-1.0.0/comm/raconfig.o
In file included from ./include/linux/workqueue.h:9:0,
from ./include/linux/srcu.h:34,
from ./include/linux/notifier.h:16,
from ./include/linux/memory_hotplug.h:7,
from ./include/linux/mmzone.h:748,
from ./include/linux/gfp.h:6,
from ./include/linux/umh.h:4,
from ./include/linux/kmod.h:22,
from ./include/linux/module.h:13,
from /opt/build/openwrt/build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/ralink_inic-1.0.0/comm/rlk_inic.h:6,
from /opt/build/openwrt/build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/ralink_inic-1.0.0/comm/raconfig.c:1:
/opt/build/openwrt/build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/ralink_inic-1.0.0/comm/raconfig.c: In function '_upload_firmware':
./include/linux/timer.h:114:27: error: passing argument 2 of 'init_timer_key' from incompatible pointer type [-Werror=incompatible-pointer-types]
init_timer_key((_timer), (_fn), (_flags), NULL, NULL)
^
./include/linux/timer.h:130:2: note: in expansion of macro '__init_timer'
__init_timer((timer), (callback), (flags))
^~~~~~~~~~~~
/opt/build/openwrt/build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/ralink_inic-1.0.0/comm/raconfig.c:1274:3: note: in expansion of macro 'timer_setup'
timer_setup(&pAd->RaCfgObj.uploadTimer, upload_timeout, 0);
^~~~~~~~~~~
./include/linux/timer.h:79:6: note: expected 'void (*)(struct timer_list *)' but argument is of type 'void (*)(uintptr_t) {aka void (*)(long unsigned int)}'
void init_timer_key(struct timer_list *timer,
^~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[4]: *** [/opt/build/openwrt/build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/ralink_inic-1.0.0/comm/raconfig.o] Error 1
make[3]: *** [_module_/opt/build/openwrt/build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/ralink_inic-1.0.0] Error 2
make[3]: Leaving directory `/opt/build/openwrt/build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/linux-4.19.56'
make[2]: *** [/opt/build/openwrt/build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/ralink_inic-1.0.0/.built] Error 2
make[2]: Leaving directory `/opt/build/openwrt/feeds/eb904_driver/kernel/ralink_inic'
time: package/feeds/eb904_driver/ralink_inic/compile#3.37#1.23#13.51
make[1]: *** [package/feeds/eb904_driver/ralink_inic/compile] Error 2
make[1]: Leaving directory `/opt/build/openwrt'
make: *** [package/ralink_inic/compile] Error 2
############################################################
At removing memdev:
I read the post Support for Easybox 904 LTE - #139 by kovz
again and again but i do not really understand it.
Anyway i search in the linked source for MII_PCDU_5_REG but i found only the definition in the linked header file
Great thanks !
I do some tests and it work like before, but the problem with SQM /sheduling / tc exist too.
Is it possible do remove some SQM /sheduling / tc stuff from the driver ?
@Plonk34 I prepared patch for PCDU setup from eth driver. Currently I do not have possibility to check it. At least, there is a main idea for replace the direct memory manipulation with devmem command. pcdu.patch
@QAuge@kovs
No i use a openwrt version (63e3c3d from 05.07) with a script like post 135:
And i split it in a SMP and VPE (with telephon) version and use the VPE version.
Sorry i have not test the raw pr001-eb904x branch itself.
OK thanks for the notice i will try to make an build with kovs patch and test it, but
my problem are that my builmaschine are 10years old Laptop or Raspberry-Pi 3 and i need always ca minimum 5hours to build.
And when someting goes wrong i have to wait 5h again.
So i hope i have an result next evening.
Don't know how to solve it. Tried rebase on previous master, but w/o success.