OpenWrt Forum Archive

Topic: Easybox 904 LTE open source code to be provide soon

The content of this topic has been archived between 1 Apr 2018 and 5 May 2018. Unfortunately there are posts – most likely complete pages – missing.

@QAuge

Many thanks for your amazing work smile Have tried the last image from 08.11. and everything is working from what I can see.
The only thing that seems a little bit strong is that the router has rebooted 2 times without any interaction from my side.

atm I'm trying to build my own Image but I lack a decent linux machine. One has to less space for the build root and the others are arm boards.
The orange pi zero compiles it at the moment but I changed some things and so I think I broke something big_smile

Are you interested in a 904 LTE Box? Have one laying around and I would spend it to you as a little present for all the work you've done big_smile

@Plonk

With the touchpad I don't have a clue but the display can configured at /etc/lcd4linux.conf

It's a simple system. You've to define some widgets, a layout, the display and there you go.

https://lcd4linux.bulix.org/wiki/Layout

But there you only can do some kind of 'static' text's which will get updated like you set in the parameters. I'm trying to find out how to play videos or stream some webcam.

@metai

Nice work, I can try the weekend if the boot animation will work on a LTE device. Can I ask how you've done this? I've tried a little bit around with binwalk but unfortunately I'm not deep enough into that reverse engineering stuff.

Do you have a little tutorial or some links where I can have at least a look how this works?

(Last edited by somebodywhoisntme on 18 Nov 2017, 02:24)

somebodywhoisntme wrote:

@metai

Nice work, I can try the weekend if the boot animation will work on a LTE device. Can I ask how you've done this?

There's actually no "reverse engineering" necessary. Have a look at the makefile in the arcadyan-tools directory of the original firmware source, it tells you how the binary blob is formatted.

Only I don't have a build environment ready, and I'm utterly unfamiliar with creating one, so I wrote a shell script based on that makefile and adapted it to work on my system (incidentally another OpenWrt/LEDE box running on a My Book Live NAS).

The whole process is actually not that complicated:

  • The animation needs to be a set of 81 images in raw format (I use ImageMagick convert to create them from a set of PNGs), and 10 more images containing the instructions displayed when flashing

  • The raw images need to be LZMA-compressed and put into a binary blob

  • Finally, the whole thing needs a 160-byte header (conveniently documented in the makefile), and if one sticks to the original number of images, the only value that varies there is the size of the LZMA blob.

I had the biggest problems with creating the lzma-compressed archive because the original "lzma" used in the makefile has been superseded by "xz tools", and even though those provide an "lzma", it is not parameter compatible with the parameters in the makefile. Maybe I was too cautious, maybe as long as it is "LZMA" of any sort the boot process decompresses everything fine, but I wanted to be as close as possible to the original compression type. And it's surprisingly hard to find information of how the "old lzma" parameters are to be substituted with the new ones from XZ tools.

I also did not try to vary the amount of images used (81) because the images after that contain instructions in emergency situations and I don't know if the bootloader is smart enough to adjust the offset for those images.

Really the only reason I did not document everything yet is the fact that my set of scripts and tools is an utterly messy hodgepodge, and has nothing in common with a clean makefile. But I'll happily help in any way I can, I have no intention of keeping this a secret.

(Last edited by metai on 18 Nov 2017, 10:04)

Alright, I finally found the time to upgrade to the latest snapshot (2017-11-08), and there's something broken in that latest snapshot.

When I sysupgrade to the 11-08 snapshot from any previous version without "keeping settings", or directly from the fullimage.img from post #280, the box boots into a state where the LAN does not work. No DHCP, no answer at 192.168.1.1, not even pings. LCD is coming up, so the system is up and running.

However, when I sysupgrade from fullimage.img to the 2017-09-02 sysupgrade, the box runs fine, also when I sysupgrade from any working snapshot to to the 2017-11-08 snapshot keeping the settings.

So I believe at least in the 2017-11-08 snapshot, the default network configuration or the initial generation thereof is b0rked. (FTR, I did not try intermediate snapshots between 2017-09-02 and 2017-11-08.)

(Last edited by metai on 19 Nov 2017, 13:37)

Some other stray observations:

The snapshot image comes with a lot of packages pre-installed. I really don't have any use for perl, adblock, collectd, and other packages so I end up uninstalling them. It would be really nice to have a "clean" build that resembles the base configuration of other LEDE devices, especially now that we can use the official repositories to install our own selection of packages.

And for the life of me, I can't figure out how to configure channels, standards or bandwidths for the wireless interfaces. Some documentation there would be greatly appreciated.

Finally, and I think I mentioned this before: The LCD, when running, is drawing a lot of CPU, I think because of the really short update intervals for some values. I have substitutes for the LCD configuration in the works that draws close to zero CPU, and also a tiny shell script as a replacement for lcdcontroller that uses almost no memory, it's just not quite ready for showtime yet.

(Last edited by metai on 19 Nov 2017, 19:48)

metai wrote:

Alright, I finally found the time to upgrade to the latest snapshot (2017-11-08), and there's something broken in that latest snapshot.

When I sysupgrade to the 11-08 snapshot from any previous version without "keeping settings", or directly from the fullimage.img from post #280, the box boots into a state where the LAN does not work. No DHCP, no answer at 192.168.1.1, not even pings. LCD is coming up, so the system is up and running.

However, when I sysupgrade from fullimage.img to the 2017-09-02 sysupgrade, the box runs fine, also when I sysupgrade from any working snapshot to to the 2017-11-08 snapshot keeping the settings.

So I believe at least in the 2017-11-08 snapshot, the default network configuration or the initial generation thereof is b0rked. (FTR, I did not try intermediate snapshots between 2017-09-02 and 2017-11-08.)

Thanks for your report! I found the commit, which prevents the correct initial config creation ( I added eth0 as default lan interface, which doesn't work: We have to use eth0.1 ). I start a new build.
I found another bug which creates a new wlan config on every sysupgrade.... I think about a fix wink

@metai

Many thanks.

Ha, I'm not really deep into that stuff and never thought of looking into the make file of the provide source code from Arcadian xD

I think I understood but somehow I don't get it to work. Googled a little bit around and found this site:

https://manned.org/lzma_alone.1



There I found the 'old lzma' parameters mentioned in the makefile.

Just for clarification I'll post the original command and the one where I think it should with xz-utils;

cat ./files/etc/lcd_boot_image/*.raw | $(STAGING_DIR_HOST)/bin/lzma e $(PKG_BUILD_DIR)/lcd_boot_image.lzma -si -a0

cat custom_boot_animation/*.raw | xz --format=lzma --lzma1=preset=0 - --stdout > lcd_boot_imgage.lzma


So the 'e' is for encoding which I assume just stands for compressing, the '-si' parameter tells lzma to take the data from stdin and the '-a0' parameter adjusts the compression-rate.

With xz-utils:

  • '--format=lzma' without '--decompress' should be the equivalent for 'lzma e'

  • '-' or nothing should be the equivalent for '-si'

  • '--lzma1=preset=0' should be the equivalent for '-a0'

  • somehow I was to stupid to declare the output file so I used '--stdout' to pipe it straight into the file(maybe that's the problem big_smile )

Buuuut, as expected this doesn't work. If I'm understand the makefile correctly the pictures won't get compressed individually rather than they get packed together in the 'lcd_boot_image.lmza' archive, correct?
Also I wonder why the heck the pictures from the source code have all the same size. The ones I converted from *.png to *.raw with ImageMagick use to have all different file sizes.


Here's the script I tried to create maybe you find the error if you like to check it:

#!/bin/bash

cat animation/*.raw | xz --format=lzma --lzma1=preset=9 - --stdout > lcd_boot_image.lzma

f_size=`du -k "lcd_boot_image.lzma" | cut -f1`

echo 'write first 16 bytes: identifier'
printf "%s" "lcd_boot_image" > lcd_boot_image
./pad2align.sh -n  16 lcd_boot_image >& /dev/null

echo 'write next 12 bytes: LZMA compressed image size'
printf "%lu" `ls -l lcd_boot_image.lzma | cut -d ' ' -f 5` >> lcd_boot_image
./pad2align.sh -n  28 lcd_boot_image >& /dev/null

echo 'write next 4 bytes: amount of files'
printf "%lu" `ls -1 animation/*.raw | wc -l` >> lcd_boot_image
./pad2align.sh -n  32 lcd_boot_image >& /dev/null

echo 'write next 16 bytes: original image size'
printf "%lu" `du -b -c animation/*.raw  | awk '{ if ( $$$$2 == "total" ) print $$$$1 }'` >> lcd_boot_image
./pad2align.sh -n  48 lcd_boot_image >& /dev/null

echo 'write next 4 bytes: frame time slot, in msec '
echo "10" >> lcd_boot_image
./pad2align.sh -n  52 lcd_boot_image >& /dev/null

echo 'write next 108 bytes: bit vector format of display images, lsb'
echo "1111111111111111111111111111111111111111111111111111111111111101010101010101010110000000000" >> lcd_boot_image
./pad2align.sh -n 160 lcd_boot_image >& /dev/null

echo 'add lcd_boot_image.lzma'
cat lcd_boot_image.lzma >> lcd_boot_image
./pad2align.sh -n $f_size lcd_boot_image >& /dev/null


BTW; I wanted to try your lcd_boot_image on the LTE box I've laying around here but now I had recognize why I didn't continued the last time I was here because somehow I messed up the box¯\_(ツ)_/¯
(sry I forgot about that @QAuge, was not my intention to offer you 'junk' big_smile)

Now somehow I'm not able to flash a image anymore but I'll try to recover it the next days.

(Last edited by somebodywhoisntme on 20 Nov 2017, 05:25)

somebodywhoisntme wrote:

I wonder why the heck the pictures from the source code have all the same size.

Raw images are uncompressed bitmaps, in our case 320x240 pixels with 8 bits (1 byte) each for R, G and B. That makes them 320*240*3 = 230400 bytes.

The ones I converted from *.png to *.raw with ImageMagick use to have all different file sizes.

Use

convert file.png -depth 8 rgb:file.raw

echo 'add lcd_boot_image.lzma'
cat lcd_boot_image.lzma >> lcd_boot_image
./pad2align.sh -n $f_size lcd_boot_image >& /dev/null

That final padding in your script is wrong. It needs to pad to a multiple of 131072 bytes (i.e., 128 kB). The original "pad2align.sh" (which, in my script, I replaced with dd commands) not only pads to a certain size, it pads to a multiple of that size.

I'm just in the process of cleaning up all my stuff over here and putting it on github, I try to finish that tonight. At least it will provide a tried and tested method.

Edit: Here it is: https://github.com/squarewf/easybox904-bootanimation

(Last edited by metai on 20 Nov 2017, 22:55)

@QAuge

Thanks for the great work.

There seems to be a problem with the wifi in your last 2017-11-19 image on box.
I followed the instructions and enabled wifi in

/etc/config/wireless

but it cannot be brought up.

Earlier builds do not seem to have this problem.

root@LEDE:~# cat /etc/config/wireless 

config wifi-device 'wl000'
        option type 'ralink'
        option channel '11'
        option disabled '0'

config wifi-iface 'default_wl000'
        option device 'wl000'
        option mode 'ap'
        option ssid 'Lede'
        option encryption 'psk2+aes'
        option key 'WiFipassword'

config wifi-device 'wl010'
        option type 'ralink'
        option channel '11'
        option disabled '0'

config wifi-iface 'default_wl010'
        option device 'wl010'
        option mode 'ap'
        option ssid 'Lede1'
        option encryption 'psk2+aes'
        option key 'WiFipassword'
root@LEDE:~# /etc/init.d/rt3883 restart ; /etc/init.d/network reload
scan device: wl000
Shutdown interface wl000
Invalid command : set
Invalid command : set
Invalid command : set
scan device: wl010
Shutdown interface wl010
Invalid command : set
Invalid command : set
Invalid command : set
scan device: wl000
Enable device wl000
DEVICE: wl000 VIF: default_wl000
Encryption: psk2+aes
Preparing interface <wl000>

Bring up interface <wl000> to be able to send iwpriv commands
Configure wifi device wl000

Starting wifi device wl000
iwpriv 'wl000' set Enable=1; iwpriv 'wl000' set Enable=0; iwpriv 'wl000' set RadioOn=0; iwpriv 'wl000' set AuthMode=WEPAUTO; iwpriv 'wl000' set EncrypType=WEP; iwpriv 'wl000' set IEEE8021X=0; echo 'wl000' is WPA2-AES MODE; iwpriv 'wl000' set AuthMode=WPA2PSK; iwpriv 'wl000' set EncrypType=AES; iwpriv 'wl000' set IEEE8021X=0; iwpriv 'wl000' set WPAPSK='WiFipassword'; iwpriv 'wl000' set DefaultKeyID=2; iwpriv 'wl000' set SSID=Lede ; iwpriv 'wl000' set Enable=1; iwpriv 'wl000' set RadioOn=1
Invalid command : set
Invalid command : set
Invalid command : set
Invalid command : set
Invalid command : set
Invalid command : set
wl000 is WPA2-AES MODE
Invalid command : set
Invalid command : set
Invalid command : set
Invalid command : set
Invalid command : set
Invalid command : set
Invalid command : set
Invalid command : set
wl000(ralink): enable failed
scan device: wl010
Enable device wl010
DEVICE: wl010 VIF: default_wl010
Encryption: psk2+aes
Preparing interface <wl010>

Bring up interface <wl010> to be able to send iwpriv commands
Configure wifi device wl010

Starting wifi device wl010
iwpriv 'wl010' set Enable=1; iwpriv 'wl010' set Enable=0; iwpriv 'wl010' set RadioOn=0; iwpriv 'wl010' set AuthMode=WEPAUTO; iwpriv 'wl010' set EncrypType=WEP; iwpriv 'wl010' set IEEE8021X=0; echo 'wl010' is WPA2-AES MODE; iwpriv 'wl010' set AuthMode=WPA2PSK; iwpriv 'wl010' set EncrypType=AES; iwpriv 'wl010' set IEEE8021X=0; iwpriv 'wl010' set WPAPSK='WiFipassword'; iwpriv 'wl010' set DefaultKeyID=2; iwpriv 'wl010' set SSID=Lede1 ; iwpriv 'wl010' set Enable=1; iwpriv 'wl010' set RadioOn=1
Invalid command : set
Invalid command : set
Invalid command : set
Invalid command : set
Invalid command : set
Invalid command : set
wl010 is WPA2-AES MODE
Invalid command : set
Invalid command : set
Invalid command : set
Invalid command : set
Invalid command : set
Invalid command : set
Invalid command : set
Invalid command : set
wl010(ralink): enable failed
guraltsev wrote:

There seems to be a problem with the wifi in your last 2017-11-19 image on box.

I cannot confirm that. I notice you use

/etc/init.d/rt3883 restart

to restart the wifi. I don't have to do that. A simple

wifi

brings up the wireless interfaces just fine.

I have finally found some time to follow up on this device. The very first issue I'm trying to tackle is the wifi.

May I ask, where is the /lib/wifi/ralink.sh coming from? It seems to try to translate OpenWrt's UCI configuration files to something the iwpriv command understands, but it stops short of even basic configuration options, most obviously the channel and bandwidth settings, and I think a lot of encryption options.

I already made some modifications to /lib/wifi/ralink.sh, so now my version will accept the channel selection in /etc/config/wireless, but I'm not sure if this is the right place to make such modifications.

metai wrote:

I already made some modifications to /lib/wifi/ralink.sh, so now my version will accept the channel selection in /etc/config/wireless, but I'm not sure if this is the right place to make such modifications.

Open PR here: https://github.com/Quallenauge/Easybox-904-XDSL

obsy wrote:
metai wrote:

I already made some modifications to /lib/wifi/ralink.sh, so now my version will accept the channel selection in /etc/config/wireless, but I'm not sure if this is the right place to make such modifications.

Open PR here: https://github.com/Quallenauge/Easybox-904-XDSL

Thank you, I'm aware of his repository and the possibility of making PRs. My question is a different one: It seems that there is still a lot to do on the wireless system, at least to bring it into the OpenWrt ecosystem, and I'm not sure if ralink.sh is the best place to make modifications. It would help to know where that file is coming from, i.e. who created it in the first place, and what the plans are for it. I notice that the wireless bringup has already changed at least once.

Other than that, I'm having a lot of problems convincing the wireless device with iwpriv. I can't seem to set a lot of parameters, no HT20, no second channel below, no base channel > 48, etc.

See post #200

(Last edited by obsy on 3 Jan 2018, 19:03)

obsy wrote:

See post #200

... which talks about GPIOs. What are you trying to tell me?

To quote QAuge:

If someone has time and would like to extend the configuration, you are welcome.

I'm trying to assess the current state of things (since they have been very much in flux since basic support was established) and how to improve them.

(Last edited by metai on 3 Jan 2018, 19:25)

guraltsev wrote:

@QAuge

Thanks for the great work.

There seems to be a problem with the wifi in your last 2017-11-19 image on box.
I followed the instructions and enabled wifi in

/etc/config/wireless

but it cannot be brought up.

Earlier builds do not seem to have this problem.

root@LEDE:~# /etc/init.d/rt3883 restart ; /etc/init.d/network reload
scan device: wl000
Shutdown interface wl000
Invalid command : set
Invalid command : set
Invalid command : set
....
wl010(ralink): enable failed

Hi @guraltsev!

Hm, such errors resulting in no or incompleted firmware uploads.
Maybe it helps if you can post some dmesg messages. Did you also changed the VLAN settings? (The device is initialized via the network interface - and in case this is blocked, the firmware can't be uploaded).

metai wrote:
obsy wrote:

See post #200

... which talks about GPIOs. What are you trying to tell me?

To quote QAuge:

If someone has time and would like to extend the configuration, you are welcome.

I'm trying to assess the current state of things (since they have been very much in flux since basic support was established) and how to improve them.

Hi @metai!
The driver we have is an old one dinosaur. It uses the legacy iwpriv ioctl-command based technique for controlling.
Newer drivers are using the cfg80211. In case someone would convert the iwpriv-ioctl calls into the cfg80211-structures we are able to use them with more power within the LuCI interface via the state of the art interfaces.
I'm not feeling, that I have the sufficient power to do that, since that seems to be a bigger job. Some help is needed from someone who's some knownledge already.

Regarding the existing configuration files:

ralink.sh

is located at the

/lib/wifi/ralink.sh

folder.
It seems, openwrt is executing all scripts within the folder. It is a standard for all drivers in openwrt. I copied&pasted the file from other wifi drivers and adapted this to support some initial parameters, like on/off channel selection, SSID and decryption settings. There are much more settings available, there is a good documentation about the available iwpriv commands here: Post 333.

QAuge wrote:

The driver we have is an old one dinosaur. It uses the legacy iwpriv ioctl-command based technique for controlling.

I noticed. Like I said, I was unsuccessful to make the driver do half the things it is supposed to do, even with iwpriv, but I now realize that the documentation I was consulting might even be for a newer or different driver. Still it's curious that even our driver is just going up to channel 48 on the 5GHz band, and going on strike on any channel beyond that. The driver clearly seems to acccept some configuration, but it is unclear (at least to me) how much and why.

I copied&pasted the file from other wifi drivers and adapted this to support some initial parameters, like on/off channel selection, SSID and decryption settings.

That was my question, sorry for being unclear. I was thinking about extending ralink.sh to accept more configuration from the UCI files, just like you ask for in post #333.

There are much more settings available, there is a good documentation about the available iwpriv commands here: Post 333.

Besides the link not actually linking to post #333, there is no reference to any documentation in post #333. Am I looking in the wrong place? Do my posts order differently?

(Last edited by metai on 4 Jan 2018, 05:29)

Sorry, indeed it is post #307.

QAuge wrote:

Sorry, indeed it is post #307.

No problem. However, I can't find any documentation for the iwpriv commands there either. The datasheets are, well, datasheets. And the link to the PDF at SourceForge leads to a "forbidden" error page. Am I being daft?

Try this one DriverNotes. I took this document as reference RT3x5x_5350_Linux_STA
Many commands are valid for our device. Also take a look at this.

(Last edited by QAuge on 4 Jan 2018, 13:30)

QAuge wrote:

Try this one

[Edited most of this post, because some of my assumptions were wrong.]

Thank you for the links. I found that your guide has quite a few errors, by the way. For example, the Parameter "CountryRegionForABand" should really be "CountryRegionABand" without the "For". Others are wrongly cased: "HTGI" or "HTBW" should be "HtGi" or "HtBw". Not that they do much other than not presenting an error.

So far I have not been able to convince the adapters to do anything but 20 MHz on 2.4GHz and 40 MHz on 5GHz, also I could not switch them into 11ac mode. The adapters' firmware seems to have a mind on its own, with some curious behaviours:

TKIP as "encryption type" for example fixes the 2.4 GHz adapter to 11g (54 mbit), switching from TKIP to AES immediately upgrades it to 11n. If the 5GHz adapter is set to any channel higher than 48 it takes the better part of a minute to come up. Sometimes, but not always, after a full reboot an uninitialized wl010 shows up as unsecured AP with 40 MHz bandwidth, something I could not make it do using iwpriv configuration. It's really a curious thing.

(I have to rely on observation since iwpriv <interface> show is not working and debug output does not travel back to OpenWrt's dmesg/log.)

(Last edited by metai on 10 Jan 2018, 07:38)

@QAuge Can You explain how did You build recovery image ?

@metai
It would be really awesome if you could help to bring the EasyBox 904 xDSL support to mainline Openwrt. Could you maybe already make the PullRequests for  those speling fixes you have find?

xicoyihl wrote:

It would be really awesome if you could help to bring the EasyBox 904 xDSL support to mainline Openwrt.

I will happily do my best, but keep in mind "my best" is superficial tinkering with shell scripts at best. I really have no deeper knowledge of how to develop for OpenWrt.

And as much as I would love mainline support for this device, I also agree with QAuge that mainline support is unlikely, the whole device seems to be one big hack.

A first step -- and, honestly, good enough for me -- would be "clean" image releases with only the most basic packages. Maybe even one with SMP and one without. At the moment we benefit from the one QAuge compiles for himself, with quite a few packages not everyone needs. But we're really very much at the grace of QAuge here.

Could you maybe already make the PullRequests for  those speling fixes you have find?

The spelling mistakes are in the documentation, not in any file.

What I can, and hopefully will do is publish improvements to the current ralink.sh file so it takes more parameters from /etc/config/wireless (at the moment it doesn't even take channels). But I'm not quite done with it yet.

(Last edited by metai on 10 Jan 2018, 17:08)

Some other developers of LEDE/OpenWrt told that mainline OpenWrt is possible.
The main reason it does not get merged at the recent state is that the changes QAuge did break the support for other devices. Thats probably the first thing that should be fixed - not breaking support for non-easybox-904-devices.

Sorry, posts 426 to 425 are missing from our archive.