Hacking COMPLETED Fusee-LEDE Dongle (6$ payload injector)

[FGFlann]

OK, so I screwed up, I edit the config files manually from h t t p s://github.com/ijuintekka/fusee-a5 but wired access no longer works for me. I think the easiest way for me to sort this is just to flash the firmware.bin.
I put it on a usb stick and inserted it into the unit, but I can't see it anywhere what's the easiest way to reflash the firmware?

I've got access via wifi and can ssh from there just fine

With your usb drive with firmware.bin inserted first type:

ls /dev/sd*

Look for your partition, it will most likely be /dev/sda1 but it could be /dev/sda in some isolated cases.

Next: mount /dev/sda1 /mnt

Where sda1 is your partition containing firmware.bin

Finally: sysupgrade -v /mnt/firmware.bin

To reflash the firmware.

 

[PC_Arcade]

nothing found with
ls /dev/sd*

 

[FGFlann]

nothing found with
/dev/sd*

Did the original firmware you flashed have USB support? Also did you flash uboot?

 

[PC_Arcade]

Not to worry, as reset seems to have fixed it, thank for the help

--------------------- MERGED ---------------------------

FGFlann, given I can now access via the PC, I'd really like to flash your version of the firmware anyway, but I can't do it via usb, how can I?

 

[FGFlann]

Not to worry, as reset seems to have fixed it, thank for the help

--------------------- MERGED ---------------------------

FGFlann, given I can now access via the PC, I'd really like to flash your version of the firmware anyway, but I can't do it via usb, how can I?

Without uboot there's no emergency recovery to restore from firmware.bin on a flash drive, you can attempt to install usb storage support manually but I can't guarantee you will have enough space on your device to do so.

You can attempt to do so by running:

opkg update; opkg install blkid block-mount kmod-usb-storage-extras kmod-fs-vfat

Which will allow you to mount FAT/FAT32 storage if successful.

 

[PC_Arcade]

seemed ok sizewise, but failed with :

* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-usb-storage-extras:
* kernel (= 4.4.139-1-0d983a7ae1ead45f22a62365d22b3104) * kernel (= 4.4.139-1-0d983a7ae1ead45f22a62365d22b3104) * kernel (= 4.4.139-1-0d983a7ae1ead45f22a62365d22b3104) *
* opkg_install_cmd: Cannot install package kmod-usb-storage-extras.
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-fs-vfat:
* kernel (= 4.4.139-1-0d983a7ae1ead45f22a62365d22b3104) * kernel (= 4.4.139-1-0d983a7ae1ead45f22a62365d22b3104) * kernel (= 4.4.139-1-0d983a7ae1ead45f22a62365d22b3104) * kernel (= 4.4.139-1-0d983a7ae1ead45f22a62365d22b3104) *
* opkg_install_cmd: Cannot install package kmod-fs-vfat.

also
Configuring block-mount.
this file has been obsoleted. please call "/sbin/block mount" directly

 

[FGFlann]

seemed ok sizewise, but failed with :

* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-usb-storage-extras:
* kernel (= 4.4.139-1-0d983a7ae1ead45f22a62365d22b3104) * kernel (= 4.4.139-1-0d983a7ae1ead45f22a62365d22b3104) * kernel (= 4.4.139-1-0d983a7ae1ead45f22a62365d22b3104) *
* opkg_install_cmd: Cannot install package kmod-usb-storage-extras.
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-fs-vfat:
* kernel (= 4.4.139-1-0d983a7ae1ead45f22a62365d22b3104) * kernel (= 4.4.139-1-0d983a7ae1ead45f22a62365d22b3104) * kernel (= 4.4.139-1-0d983a7ae1ead45f22a62365d22b3104) * kernel (= 4.4.139-1-0d983a7ae1ead45f22a62365d22b3104) *
* opkg_install_cmd: Cannot install package kmod-fs-vfat.

Unfortunately I can't help you from this point. I'm very sorry. Perhaps someone more familiar with the process can give you some insight but I wouldn't know who to refer you to.

 

[PC_Arcade]

That's ok, thank you for the help you did give

 

[Wierd_w]

Unfortunately I can't help you from this point. I'm very sorry. Perhaps someone more familiar with the process can give you some insight but I wouldn't know who to refer you to.

The issue is that the kernel running is not the "official build" kernel from the repositories. He needs the packages that get built by the compiler when the image is generated if he intends to install kernel modules, which includes filesystem drivers and USB class drivers. Short of building it himself, the people who are making the images need to provide the packages folder in the output folder on something like google drive. People can then manually install a package using a combination of wget and opkg. (use wget to pull the .ipk file onto local storage, (/tmp mount with tmpfs works fine in most cases) then install it with syntax similar to this: opkg install "\somepath\someipk.ipk")

This is because openwrt enforces kernel magic numbers to assure that malicious modules not compiled at the same time as the kernel cannot be loaded. It's a security feature.

So, if you are making easily installed firmware images, please put the compiled packages folder online somewhere, and tell people where it is.

 

[FGFlann]

The issue is that the kernel running is not the "official build" kernel from the repositories. He needs the packages that get built by the compiler when the image is generated if he intends to install kernel modules, which includes filesystem drivers and USB class drivers. Short of building it himself, the people who are making the images need to provide the packages folder in the output folder on something like google drive. People can then manually install a package using a combination of wget and opkg. (use wget to pull the .ipk file onto local storage, (/tmp mount with tmpfs works fine in most cases) then install it with syntax similar to this: opkg install "\somepath\someipk.ipk")

This is because openwrt enforces kernel magic numbers to assure that malicious modules not compiled at the same time as the kernel cannot be loaded. It's a security feature.

So, if you are making easily installed firmware images, please put the compiled packages folder online somewhere, and tell people where it is.

I don't have the means to do this. In addition, the image in question is not mine.

 

[PC_Arcade]

Funnily enough I did build a version myself and I have all of the packages, but I don't know which I need.

I can put them somewhere for everyone as well if needed

 

[OkazakiTheOtaku]

SXOS payload as default (this one has not been tested, use it at your own risks, please report if OK)

I did some experimenting, and this firmware does not work and causes a soft-brick to the device. If this firmware.bin is flashed, the router boot loops until you flash @FGFlann 's firmware.bin on boot by using the reset button. If you didn't install uboot before that, you're SOL.

Also, when you use FGFlann's to boot, it has to be flashed manually using the `sysupgrade`command or it will boot loop again.

 

[PC_Arcade]

I flashed the SXOS payload version and mine is working although I had to do a full reset to get it to do so
Works launching the SXOS payload everytime for me!

 

[OkazakiTheOtaku]

I flashed the SXOS payload version and mine is working although I had to do a full reset to get it to do so
Works launching the SXOS payload everytime for me!

Is that so? We must have different hardware. I just used @FGFlann's firmware and replaced the payload with the SX one. Works perfectly fine and I like the SSH functions as they are configured.

 

[FGFlann]

As long as you have a working device and are happy with it that's all that matters. It's still possible to swap payloads since you have SSH and internet access. I just wish we could do more to help you get the ability to flash a recovery image should you need to.

 

[FGFlann]

@PC_Arcade
I just noticed there is enough space on /tmp to attempt flashing another image.

You will have to pull it from another server with wget but it should be doable if you want to make the attempt. But I'm hesitant to do another flash with no way to restore it should it go bad.

 

[PC_Arcade]

Yeah, I think I agree with you on that....

--------------------- MERGED ---------------------------

Although...

Filesystem                Size      Used Available Use% Mounted on
/dev/root                 2.0M      2.0M         0 100% /rom
tmpfs                    14.0M     72.0K     13.9M   1% /tmp
/dev/mtdblock6          744.0K    272.0K    472.0K  37% /overlay
overlayfs:/overlay      744.0K    272.0K    472.0K  37% /
tmpfs                   512.0K         0    512.0K   0% /dev

@FGFlann If I were to risk it how would I (for example) install Uboot?

 

[FGFlann]

Yeah, I think I agree with you on that....

--------------------- MERGED ---------------------------

Although...

Filesystem Size Used Available Use% Mounted on
/dev/root 2.0M 2.0M 0 100% /rom
tmpfs 14.0M 72.0K 13.9M 1% /tmp
/dev/mtdblock6 744.0K 272.0K 472.0K 37% /overlay
overlayfs:/overlay 744.0K 272.0K 472.0K 37% /
tmpfs 512.0K 0 512.0K 0% /dev

@FGFlann If I were to risk it how would I (for example) install Uboot?

That's the sticking point. I've found precious few resources on how to do this and most point to flashing uboot by serial, which is going to require someone with more specialized knowledge than me to guide you through it. The other suggestion was to build a customized lede image that allows you to do this, which again I wouldn't know how to do.

 

[PC_Arcade]

and that again would need to be flashed....catch 22

I think I may have to leave it as is (no biggie to be honest)

 

[Wierd_w]

and that again would need to be flashed....catch 22

I think I may have to leave it as is (no biggie to be honest)

uboot listens on the serial console for typically 3 seconds, before initiating autoboot. In that time, you can send any character string (key press), and halt autoboot, and then control uboot over the serial console.

uboot has options to allow you to push a kernel and rootfs image to the device's ram for prototyping (OR RECOVERY!), and also has provisions for sending a new firmware file to be directly written to the flash. (More dangerous, but doable. It can accept serial data transfer using xmodem and pals. PuTTY supports these methods.

Not all of these device provide a serial debug port however!! Even when they do, they are typically just naked solder pads, and will need headers attached, and you will need a 3.3v FTDI type serial cable.

For more detailed descriptions of what all you can do with uboot over the serial console, I suggest reviewing uboot's documentation.



the *IDEAL* solution would have uboot temporarily place the ethernet port onto a fixed IP, and have it listen for a special byte sequence over telnet for 3 seconds (then allow uboot control over telnet), then have it check the USB port for appropriate image files, then finally boot the MTD.

This would allow maximal control of the hardware even on devices that lack serial debug.