[PLUG] Router configuration: connecting laptop

Russell Senior russell at personaltelco.net
Fri Dec 6 22:12:46 UTC 2019


On Fri, Dec 6, 2019 at 12:41 PM wes <plug at the-wes.com> wrote:

> On Fri, Dec 6, 2019 at 11:11 AM Louis Kowolowski <louisk at cryptomonkeys.org
> >
> wrote:
>
> > If you’re getting “file too large”, its probably the client complaining,
> > not the server.
>
>
> One would reasonably think that, but no. This was output in the server log.
> Literally "file to large" (grammar error included).
>
> When I’ve had that in the past, its because legacy firmware made
> > assumptions about file size and there was some intermediate firmware that
> > fixed it, allowing you to move forward.
>
>
> Note that we're not even uploading a firmware file at this stage; we are
> merely booting a temporary OS which will then be used to update the
> router's actual firmware. This is the way the edgerouter people want us to
> do it.
>

You are on the right track.

What is going on here is that the ERX device uses NAND flash. NAND flash
tends to be much larger than the alternative NOR flash but is also prone to
bad blocks, and you need a layer of abstraction to deal with the bad blocks
and wear leveling so other layers don't need to deal with it, and that
layer in this instance is something called UBI (unsorted block image). Note
that confusingly, UBIFS is something different than UBI, but is usually
used on top of the UBI block layer. NOR flash generally doesn't have this
bad block problem, and the flash process for NOR flash is much simpler.
With NAND flash, particularly in this recovery scenario, more tools are
required than typically are present in the bootloader. For example, you
might need to remove, resize and/or recreate the partition-like volumes
that are allocated from the UBI block layer. Booting an initramfs image
over the network (from an off-device TFTP server) provides the needed tools
without modifying the underlying flash.

When I was investigating this problem for Rich, I found that the expedient
recovery process involved booting an OpenWrt initramfs image, and (with the
tools that come with that) manipulate the contents of the flash to correct
whatever is wrong. OpenWrt and the Ubiquiti stock firmware organize things
differently. On this device, OpenWrt would create a UBI volume for a
read-only squashfs file system, and another UBI volume with whatever space
is left over for a writable filesystem, which is overlaid (with overlayfs)
on top of the squashfs to give the appearance of a fully writable
filesystem with the ability to recover to a known good state. In the case
of Ubiquiti's stock firmware, they create a large UBIFS filesystem and put
read-only images and integrity hashes as regular files on that. The system
can check that they are okay and load them. In addition, they put
configuration information in directory trees directly on the UBIFS as well.
This provides some scaffolding for having two versions of their firmware on
the system at the same time (new vs old). What I remember (memory that has
become wobbly in the week or so since I was looking at this) is that
probably the easiest way to recover Rich's bricked device is to do the
initramfs boot of OpenWrt and then just delete the configuration trees in
Ubiquiti's UBIFS, and then reboot. The Ubiquiti firmware is smart enough to
reconstruct the configuration info it needs from nothing, but it's confused
by the configuration that's there now. Anyway, that was my educated guess.

Because of Rich's difficulty in getting a simple ethernet configuration to
work, I didn't want to try to talk him through this fairly complex and
fiddly process over email.

Note, the ERX device loads initramfs images as a client from a remote TFTP
server. To initramfs boot, you put the image on the server and use a serial
console to tell the ERX to fetch the initramfs to RAM. You use the serial
console to interrupt the normal boot process and select the initramfs boot,
and then tell the ERX what its ip address is, what the server ip address
is, and what the filename is relative to the TFTP server space.


>
>
> > You may also be able to use a different protocol to copy the file. Many
> > modern devices will allow http(s)/scp/ftp/tftp.
> >
> >
> I did not find any mention of the edgerouter boot ROM supporting this. If
> you can find evidence of it, please share.
>
> -wes
> _______________________________________________
> PLUG mailing list
> PLUG at pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>



More information about the PLUG mailing list