The Full VPE version with Asterisk, DSL port as a xDSL link yields a file of 0 bytes length.
I successfully installed Zuzia's fullimage. When I try to flash a sysupgrade image via LuCI I get
"1,Operation not permitted
Upload request failed: Upload permission denied"
@gschwarz
Sysupgrade is working properly. It's all working very well and quickly. I want you to watch a short video from my latest upgrade via Luci.
https://streamable.com/y07gm2
Thanks for your reply. It turned out that Firefox mistook openwrt-lantiq-xrx200-arcadyan_vgv952cjw33-e-ir-vpe-xdsl-squashfs-sysupgrade.bin for malware and cancelled the download. When I use e.g. wget to fetch the file, it now works fine, just as you showed in your video.
However, if I try a sysupgrade using an older sysupgrade file such as 2020-07-10_openwrt-lantiq-xrx200-arcadyan_vgv952cjw33-e-ir-smp-squashfs-sysupgrade.bin I get:
"Device arcadyan,vgv952cjw33-e-ir-vpe not supported by this image Supported devices: arcadyan,vgv952cjw33-e-ir-smp VGV952CJW33-E-IR VGV952CJW33-E-IR Image check failed.
The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform."
Is this due to SMP support in that sysupgrade image?
Anyway, I'll gladly test Zuzia's image.
Here's the first issue I came across. I tried the DSL modem on a VDSL line with 17a profile (vectoring) which with a modern AVM Frtitzbox DSL router syncs at 110/37 Mbit/s.
With the 904xdsl I get:
root@EasyBOX: etc$ ./init.d/dsl_control dslstat
ATU-C Vendor ID: Broadcom 194.80
ATU-C System Vendor ID: Broadcom
Chipset: Lantiq-VRX200
Firmware Version: 5.9.1.4.0.7
API Version: 4.17.18.6
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.2 (VDSL2)
Profile: 17a
Line State: UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS): Near: 0 / Far: 177
Errored seconds (ES): Near: 0 / Far: 5
Severely Errored Seconds (SES): Near: 0 / Far: 1
Loss of Signal Seconds (LOSS): Near: 4 / Far: 1
Unavailable Seconds (UAS): Near: 1156 / Far: 1156
Header Error Code Errors (HEC): Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P): Near: 0 / Far: 0
Pre-emtive CRC errors (CRCP_P): Near: 0 / Far: 0
Power Management Mode: L0 - Synchronized
Latency [Interleave Delay]: 0.60 ms [Fast] 11.0 ms [Interleave]
Data Rate: Down: 23.473 Mb/s / Up: 1.311 Mb/s
Line Attenuation (LATN): Down: 6.1 dB / Up: 3.3 dB
Signal Attenuation (SATN): Down: 6.1 dB / Up: 3.3 dB
Noise Margin (SNR): Down: 7.0 dB / Up: 9.1 dB
Aggregate Transmit Power (ACTATP): Down: 13.7 dB / Up: 13.2 dB
Max. Attainable Data Rate (ATTNDR): Down: 24.215 Mb/s / Up: 1.371 Mb/s
Line Uptime Seconds: 22
Line Uptime: 22s
even through I tried firmwares 5.9.0.C.1.7-5.9.0.A.0.2 and 5.9.1.4.0.7-5.9.0.D.0.2 (cf. https://xdarklight.github.io/lantiq-xdsl-firmware-info/) in addition to the firmware built into the image (the latter I had not expected to support vectoring).
Looks like Vectoring does not work even with the DSL firmware images extracted from AVM's upgrade files?
With exactly the same DSL firmware files I get syncs at about 100/35 Mbit/s on an O2 box 6432 running OpenWRT (on the same DSL line of course).
It's not a problem, ignore the message and force the upgrade.
I see. What is causing that message to come up, i.e. why does the check fail?
Contrary to what I wrote above, Vectoring does work on this box. It just seems to be necessary to reboot after changing the DSL firmware. Here are the results with three DSL firmwares:
from AVM Fritzbox 7412 last stable image:
ATU-C Vendor ID: Broadcom 194.80
ATU-C System Vendor ID: Broadcom
Chipset: Lantiq-VRX200
Firmware Version: 5.9.0.12.1.7
API Version: 4.17.18.6
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.5 (VDSL2 with down- and upstream vectoring)
Profile: 17a
Line State: UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS): Near: 0 / Far: 361
Errored seconds (ES): Near: 0 / Far: 8
Severely Errored Seconds (SES): Near: 0 / Far: 1
Loss of Signal Seconds (LOSS): Near: 0 / Far: 1
Unavailable Seconds (UAS): Near: 51522646 / Far: 51522646
Header Error Code Errors (HEC): Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P): Near: 0 / Far: 0
Pre-emtive CRC errors (CRCP_P): Near: 0 / Far: 0
Power Management Mode: L0 - Synchronized
Latency [Interleave Delay]: 0.15 ms [Fast] 0.0 ms [Fast]
Data Rate: Down: 109.981 Mb/s / Up: 36.994 Mb/s
Line Attenuation (LATN): Down: 11.8 dB / Up: 11.7 dB
Signal Attenuation (SATN): Down: 11.8 dB / Up: 11.7 dB
Noise Margin (SNR): Down: 10.1 dB / Up: 8.9 dB
Aggregate Transmit Power (ACTATP): Down: 0.9 dB / Up: 14.5 dB
Max. Attainable Data Rate (ATTNDR): Down: 109.860 Mb/s / Up: 37.014 Mb/s
Line Uptime Seconds: 42
Line Uptime: 42s
from AVM Fritzbox 7490 last stable image:
ATU-C Vendor ID:
ATU-C System Vendor ID:
Chipset: Lantiq-VRX200
Firmware Version: 5.9.1.4.0.7
API Version: 4.17.18.6
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.5 (VDSL2 with down- and upstream vectoring)
Profile: 17a
Line State: UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS): Near: 0 / Far: 361
Errored seconds (ES): Near: 0 / Far: 8
Severely Errored Seconds (SES): Near: 0 / Far: 1
Loss of Signal Seconds (LOSS): Near: 0 / Far: 1
Unavailable Seconds (UAS): Near: 179 / Far: 179
Header Error Code Errors (HEC): Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P): Near: 0 / Far: 0
Pre-emtive CRC errors (CRCP_P): Near: 0 / Far: 0
Power Management Mode: L0 - Synchronized
Latency [Interleave Delay]: 0.15 ms [Fast] 0.0 ms [Fast]
Data Rate: Down: 109.981 Mb/s / Up: 36.890 Mb/s
Line Attenuation (LATN): Down: 11.8 dB / Up: 11.7 dB
Signal Attenuation (SATN): Down: 11.8 dB / Up: 11.6 dB
Noise Margin (SNR): Down: 9.5 dB / Up: 8.8 dB
Aggregate Transmit Power (ACTATP): Down: 0.9 dB / Up: 14.4 dB
Max. Attainable Data Rate (ATTNDR): Down: 122.732 Mb/s / Up: 36.894 Mb/s
Line Uptime Seconds: 34
Line Uptime: 34s
from Vodafone Easybox 904 last stable image:
ATU-C Vendor ID:
ATU-C System Vendor ID:
Chipset: Lantiq-VRX200
Firmware Version: 5.7.3.3.0.7
API Version: 4.17.18.6
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.5 (VDSL2 with down- and upstream vectoring)
Profile: 17a
Line State: UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS): Near: 0 / Far: 361
Errored seconds (ES): Near: 0 / Far: 8
Severely Errored Seconds (SES): Near: 0 / Far: 1
Loss of Signal Seconds (LOSS): Near: 0 / Far: 1
Unavailable Seconds (UAS): Near: 175 / Far: 175
Header Error Code Errors (HEC): Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P): Near: 0 / Far: 0
Pre-emtive CRC errors (CRCP_P): Near: 0 / Far: 0
Power Management Mode: L0 - Synchronized
Latency [Interleave Delay]: 0.13 ms [Fast] 0.0 ms [Fast]
Data Rate: Down: 107.723 Mb/s / Up: 36.154 Mb/s
Line Attenuation (LATN): Down: 11.0 dB / Up: 11.8 dB
Signal Attenuation (SATN): Down: 11.0 dB / Up: 11.9 dB
Noise Margin (SNR): Down: 9.4 dB / Up: 9.0 dB
Aggregate Transmit Power (ACTATP): Down: -1.8 dB / Up: 14.5 dB
Max. Attainable Data Rate (ATTNDR): Down: 119.936 Mb/s / Up: 36.158 Mb/s
Line Uptime Seconds: 14
Line Uptime: 14s
So it does not seem to make much of a difference.
**New fullimage.img [SMP & VPE] **
Luci (en, de, pl), LCD+touchkeys, 3G/LTE modems, DHCP server, DSL port as a WAN, filesystem ext4, vfat, msdos, f2fs.
...via ssh:
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
---------------------------------------------------------
Recovery OpenWrt Easybox 904 xDSL / Kernel SMP 4.19.138
---------------------------------------------------------
| Machine: Easybox 904xDSL |
| Uptime: 0d, 00:04:05 |
| Load: 0.31 0.39 0.18 |
| Flash: total: 58.0MB, free: 46.3MB, used: 20% |
| Memory: total: 120.0MB, free: 104.9MB, used: 12% |
| Leases: 1 |
| lan: static, 192.168.1.1 |
| wan: dhcp, 192.168.0.2 |
| inic: none, no IP address |
| hilink: dhcp, 192.168.8.100 |
| wwan: dhcp, no IP address |
| umts: 3g, 100.117.16.172 |
| NCM: ncm, no IP address |
---------------------------------------------------------
Based on Quallenauge's sources, Plonkbong's script and
the openwrt development snapshot, I've compiled a
new snapshot with kernel 5.4.59.
For the Easybox 904 LTE I've translated the sources
from uwehermann some time ago because there are
always questions about it.
Versions for the xDSL as well as for LTE
of the Easybox can be found here:
After about five warm boots my Easybox 904 displays a nicely formatted message (in German) and a logo, asking the user to power-cycle the box:
"Ihre Easybox muss neu gestartet werden!
[Logo of a green arrow as a circle]
Schalten Sie bitte Ihre Easybox
für mindestens 10 Sekunden aus und
danach wieder ein."
I guess this is triggered by some counter in the firmware implemented with the idea of taking care of suspected repeated software crashes.
Is this something that could be disabled/overridden without changing the box's boot code?
Could OpenWRT reset that counter after a successful startup?
Yes, there is such a counter, and I distinctly remember someone (@QAuge?) proposing a patch that resets it when OpenWrt is booted successfully. However, I can't find the respective posts anymore. Edit: there it is.
I just installed Zuzia's recent fullimage (SMP version). I was surprised it's less than 5 MB in length.
Accessing the box via LuCI I cannot get past the login screen (http://192.168.1.1/cgi-bin/luci/).
Whenever I hit login it seems to revert to that page.
ssh login does work.
It's also unfortunate that dmesg functionality is not compiled in. Syslog also seems to be absent.
@QAuge
Vlan eth0.2 not working. What's changed in kernel 5.4?
Thank you for your work.
...because file fullimage.img must not exceed the size of the 5MB. Use logread. Luci works fine. Clear your web browser's cache or change browser.
Mostly adapting the ralink wifi driver,
Stability fix (workaround) for the warm reboots at the booting stage, see posts above.
Regarding the lantiq switch, none. That's very mysterious why the vlan isn't working correctly.
What isn't working in detail (can you guide me to that point? And, don't laugh 
for what was eth0.2 vlan again?).
Regarding the reset functionality: it should be enabled and resets the bootnum uot parameter not every but every x reboots:
Currently I'm at holiday trip, so I can respond in detail in some weeks.
1 Like
Thanks; indeed LuCI works fine.
One very minor cosmetic detail: the "temperature" string seems to be lacking an English and German locale, making it resort to the Polish string.
Today I played aroud a bit with wifi using uci to configure it (using Zuzia's previous image, i.e. kernel 4.19.138). As for my tests, everything worked as it should. I am wondering though whether the box has to be rebooted before changes (e.g. enabling or disabling wifi or changing the SSID) take effect? Using uci commit wireless did not result in a change; the changes went into effect only after a subsequent reboot.
In general, things are already looking very fine for 904 xdsl support. What's the current obstacles that still prevent merging support into the main OpenWRT branch?
It never does, uci commit only commits the changes to the configuration files, but does not apply them. You need to issue wifi to restart the wireless interfaces with the current configuration.