OpenWrt Forum Archive

Topic: Sky Wireless Booster - AirTies Air4400

The content of this topic has been archived between 22 Apr 2018 and 24 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Atarii wrote:

Just wanted to confirm, enabling telnet works. I connected up a serial cable and sent the following:

bcm5357 # nvram set TELNET_ENABLED=ON

*** command status = 0

bcm5357 # nvram commit

Writing nvram to 1. slot. Rev: 479

Writing nvram to 2. slot. Rev: 480

Thanks for your input Zajec, shame it's not simple to get OpenWRT on the device. sad

Regarding the Telnet. I enabled it a few days ago and couldn't login via Telnet. It enabled and stayed set after power cycles.

I tried via ethernet cable setting my laptop IP to 192.168.2.100 with the booster being 192.168.2.1 (it is pingable) but Telnet just caused Putty to hang/crash. Maybe I'm doing something wrong.

ant_thomas wrote:
Atarii wrote:

Just wanted to confirm, enabling telnet works. I connected up a serial cable and sent the following:

bcm5357 # nvram set TELNET_ENABLED=ON

*** command status = 0

bcm5357 # nvram commit

Writing nvram to 1. slot. Rev: 479

Writing nvram to 2. slot. Rev: 480

Thanks for your input Zajec, shame it's not simple to get OpenWRT on the device. sad

Regarding the Telnet. I enabled it a few days ago and couldn't login via Telnet. It enabled and stayed set after power cycles.

I tried via ethernet cable setting my laptop IP to 192.168.2.100 with the booster being 192.168.2.1 (it is pingable) but Telnet just caused Putty to hang/crash. Maybe I'm doing something wrong.

Hey ant_thomas. smile Did you try logging in with standard telnet executable (you mentioned PuTTY)? It worked fine for me; credentials being default admin/sky. I got 192.168.2.103 IP via DHCP (that shouldn't affect it though)

Quick update with some progress; I think you can disable the kernel and rootfs checks by setting "dualimage=disabled" in nvram. Now going to attempt to modify a rootfs image to verify it boots with it

Atarii wrote:

Quick update with some progress; I think you can disable the kernel and rootfs checks by setting "dualimage=disabled" in nvram. Now going to attempt to modify a rootfs image to verify it boots with it

Did you make any progress with booting a modified image?

ant_thomas wrote:
Atarii wrote:

Quick update with some progress; I think you can disable the kernel and rootfs checks by setting "dualimage=disabled" in nvram. Now going to attempt to modify a rootfs image to verify it boots with it

Did you make any progress with booting a modified image?

Hey ant_thomas. I've still working on it. I've been battling with tftp protocol for the last few days and the built-in CFE save/flash/readflash/writeflash commands. I've just got it working this evening, so will make some backups with save first and check the addresses of the rootfs/kernel etc. Then I can flash my modified rootfs. I didn't want to flash without double-checking first and end up trying to recover via JTAG. roll

(Last edited by Atarii on 17 Jan 2014, 22:01)

Update: success smile

I successfully got a modified rootfs booting:

# uname -a
Linux skywirelessbooster 2.6.22 #1 Fri Oct 25 21:46:20 EEST 2013 mips GNU/Linux
# fwversion
Responses:
sysmgr-0:fwversion 1.0.0.31
# ls -l /etc/test
-rw-r--r-- 1 root root 8 Jan 22 2014 /etc/test
# cat /etc/test
Success

This worked with dualimage=disabled set in nvram, a modified rootfs image and stock sky kernel/boot.

Worth noting that the 'rootfs' partition (accessed via load/save/readflash/writeflash commands) actually contains the boot, kernel and rootfs. So if you want to create a custom one, you will need to generate a squashfs image for the rootfs and concatenate it onto the end of the boot and kernel images.

I was stuck for a while with mksquashfs, it was rejecting any squashfs images I created. Eventually it worked using  'squashfs-3.2-r2-wnr1000' version from firmware-mod-kit

To write a new rootfs partition from CFE, you'll need to get tftpd working on a laptop/PC then:

load -tftp -raw -addr=0x80200000 192.168.2.103:newrootfs.bin -max=3599922
writeflash rootfs 0x36ee32

This copies the newrootfs.bin file from 192.168.2.103 (via tftp) to memory address 0x80200000. Then, the writeflash command copies the contents of the memory at 0x80200000 to the rootfs partition (at 0xDA580).

You might want to backup the contents of the partitions first:

readflash rootfs 0x003CFFFF
save 192.168.2.103:rootfs_backup.bin 0x80200000 0x003CFFFF

This does the opposite, copies the contents of the rootfs partition into memory (at 0x80200000), then transfers that over tftp to rootfs_backup.bin at 192.168.2.103.

Sidenote, I was also able to get the original Air4400 firmware booting this way.

Next up, building an OpenWRT image.

Just as an aside, as I was trying to get the booster working as an Access Point I have discovered that the hidden page /lan/operation_mode.html has within the code two options, the first as a booster and the second as an AP. Unfortunately the page does not load correctly throwing up errors and the Submit / Cancel buttons are commented out in code. I'm sure there will be an easy way to submit a correct response to the booster to get it to switch modes...

Hello,

I was wanting to set it up in access point mode so I could run a cable to a area of no reception.

I wrote a tamper monkey script for /lan/operation_mode.html I tried both setting selectedOptMode = "router" and "ap".
Other than making the light flash a lot a rebooting it in to quick setup mode it didn't do much.

Thanks, I look forward to be able to put openwrt on it.

Atarii...

Fantastic work! Looks like there might well be a chance then!

Hey itsbebbo and tactmaster, good to see some more Wireless Booster owners in here smile

Regarding the Router Mode, I get the same as you guys, no luck there yet. When using the original 4400 rootfs, the /lan/operation_mode.html page appears to send the right POST api call, but I also get no change on reboot.

I've also tried manually saving/writing over the config partition with the changed value:

    <product>
        <product-0>
            <log>
                <level>crit</level>
            </log>
            <settings>
                <router_mode>router</router_mode>
                <mac>00:00:00:00:00:00</mac>
            </settings>
        </product-0>
    </product>

But this still appears to boot into Access Point mode. sad

Actually, I might try setting that mac value to something sane (only just noticed it was blank when pasting this)!

As for OpenWRT, still working on getting a build, not much to report yet.

I noticed that with the from the /lan/operation_mode.html page it was reporting the current mode being "ap"

However just to note it is not working in access point mode. It is working in bridge mode + repeater mode.
* When it is not in range of the original router it doesn't give off a signal. (and switches it own dhcp on)
* When in it is in range you can plug a computer in and it can get on the network connection from it

Thanks, as some point I may get a serial cable to have a deeper play. However I will poke in any other way I can till then.

Another quick update.

Got OpenWRT built and booting:

Screenshot

I need to create patches to add in board detection and still need to sort out the partitions, as this was only booting using the CFE command:

boot -elf -tftp 192.168.2.103:openwrt-brcm47xx-vmlinux-initramfs.elf -max=6641696

CPU, flash chip and memory all detected correct values, ethernet is up, but there's no wifi yet.

Any progress on this?

I've just received one of these devices (and interestingly got it semi-working in AP mode, but as of yet have not been able to set the Wireless settings).

I'd love to help get OpenWRT working on the device, is there any way I can help?

A_Porcupine wrote:

Any progress on this?

I've just received one of these devices (and interestingly got it semi-working in AP mode, but as of yet have not been able to set the Wireless settings).

I'd love to help get OpenWRT working on the device, is there any way I can help?

Hey A_Porcupine smile So, I've got the board detection patches done; it correctly detects the device on boot. The two main things missing now are:

1. Flashing to device
     -  Currently I'm booting OpenWRT via tftp, any builds I've flashed to the device won't boot
2. Wifi
     - No working wifi at the moment; I suspect I haven't selected the correct drivers when compiling?

I could upload my .config file if you guys like, or the .elf build if you've got a serial interface to work with?

Edit: I worked it out!

If you could upload the .config and .elf that would be good as I've got a serial connection working now.

(Last edited by A_Porcupine on 12 Feb 2014, 22:39)

A_Porcupine wrote:

Edit: I worked it out!

If you could upload the .config and .elf that would be good as I've got a serial connection working now.

Nice work smile

Don't foget to make some backups before you do anything wink

Here's my pre-build vmliunx-initramfs.elf for you to try:  openwrt-brcm47xx-vmlinux-initramfs.elf
You can boot it from CFE with (laptop with tftpd running and ip 192.168.2.103, file in /var/lib/tftpboot with 777 permissions):

boot -elf -tftp 192.168.2.103:openwrt-brcm47xx-vmlinux-initramfs.elf -max=5967656

And here's my current .config build file: config
This version has the b43 wireless driver selected.

I'm still at the same point; wifi not working and unable to flash to device correctly. Currently trying the different wireless drivers (b43, broadcom-wl etc.) from here: http://wiki.openwrt.org/doc/hardware/so … om.bcm47xx to see if I can get wireless working.

The wireless chip is the broadcom bcm5357

Someone has posted internal pictures here

According to kernel log with Sky/Airties firmware:
:sta0: Broadcom BCM4329 802.11 Wireless Controller 5.100.138.2001  (WLTEST)
Also looks like it is using a proprietary Broadcom wl driver.

Great to see a decent amount of progress here, definitely glad I posted about this and got the photos up.

Mine is still open in the hope I can get OpenWRT on to it (and because it was a pain to open!)

Will be very good when this is working smile

Out of interested has anyone managed to put the original airties firmware on it rather than the sky customer firmware?

Thanks

Did anyone manage to make anymore progress on this?

ant_thomas wrote:

Great to see a decent amount of progress here, definitely glad I posted about this and got the photos up.

Mine is still open in the hope I can get OpenWRT on to it (and because it was a pain to open!)

Do you have a few pointers to opening up the case?

Squared off end of a small craft knife  approximately 1 cm into one of the two 0.5 mm slots on the base. Lever the shaft of the craft knife away from the unit and apply pressure to separate the top from the bottom and it pops open.

(Last edited by john.ohare on 29 May 2014, 22:47)

Atarii wrote:

Update: success smile

I successfully got a modified rootfs booting:

# uname -a
Linux skywirelessbooster 2.6.22 #1 Fri Oct 25 21:46:20 EEST 2013 mips GNU/Linux
# fwversion
Responses:
sysmgr-0:fwversion 1.0.0.31
# ls -l /etc/test
-rw-r--r-- 1 root root 8 Jan 22 2014 /etc/test
# cat /etc/test
Success

This worked with dualimage=disabled set in nvram, a modified rootfs image and stock sky kernel/boot.

Worth noting that the 'rootfs' partition (accessed via load/save/readflash/writeflash commands) actually contains the boot, kernel and rootfs. So if you want to create a custom one, you will need to generate a squashfs image for the rootfs and concatenate it onto the end of the boot and kernel images.

I was stuck for a while with mksquashfs, it was rejecting any squashfs images I created. Eventually it worked using  'squashfs-3.2-r2-wnr1000' version from firmware-mod-kit

To write a new rootfs partition from CFE, you'll need to get tftpd working on a laptop/PC then:

load -tftp -raw -addr=0x80200000 192.168.2.103:newrootfs.bin -max=3599922
writeflash rootfs 0x36ee32

This copies the newrootfs.bin file from 192.168.2.103 (via tftp) to memory address 0x80200000. Then, the writeflash command copies the contents of the memory at 0x80200000 to the rootfs partition (at 0xDA580).

You might want to backup the contents of the partitions first:

readflash rootfs 0x003CFFFF
save 192.168.2.103:rootfs_backup.bin 0x80200000 0x003CFFFF

This does the opposite, copies the contents of the rootfs partition into memory (at 0x80200000), then transfers that over tftp to rootfs_backup.bin at 192.168.2.103.

Sidenote, I was also able to get the original Air4400 firmware booting this way.

I tried this and found myself with a kernal panic and no-boot. Repeated and still no joy. SO I re-enabled dualboot in NVRAM and then power cycled. On rebooting the unit repaired itself! Very helpful.

Has anyone managed to get the stock Airties firmware to load on one of these re branded devices?

I have a South African version which originally had the stock firmware, was then "upgraded" to the custom firmware but now cannot go back to the stock version.

The custom firmware disables the WiFi repeater function which would be really nice to have back.

I have tried many of the options listed here, but can't seem to get into the CFE menu and the pinout at the start is different to my device, which only has 4 pins?

Thanks
Mark

I see there has been no activity since last year before last on this topic.
Can anyone, perhaps the author Atarii can assist me with getting up to speed so I can tackle the issue with the Wifi driver?

I have two of these, and I really want to unlock their capabilities, the hardware is good, and it would be great to be able to flash OpenWRT on them.

The ones sold now are provided already with the newer firmware that prevents the device from being set in repeater or AP mode.

The discussion might have continued from here.