HTTP Internet booting stock OpenWrt image

[lleachii]

Maybe it should be noted how devices are loaded [securely] in environments:

• DHCP or some other boot method tells the device it's IP and instructions to load via TFTP
• The bootloader loads the file into memory and executes

Note:

• DHCP servers are local
• This means the method cannot be used to load routers that provide the Internet connectivity to said DHCP/TFTP device; or if it needs to load new software or a new address...

Unless of course, you wish to run into race conditions...or in layperson terms - the chicken-or-the-egg problem.

Also...you're describing "nested booting" (i.e. pass from one bootloader to another). I'm only aware of this in the i686/x86_64 types of processors.

..really, this is easier than just using the methods to update with needed packages. I can only imagine if this device isn't supported by OpenWrt at this point....what is the device BTW?

@slh

automated image downloads can be seen as DoS attack against the download servers and may be blocked (do talk to the server maintainers first and get their buy-in, cache locally).

e.g. someone wanted/had a company where they always provided up-to-date router software for their devices, bootstrapped upon each fresh boot

[flygarn12]

@faxloop

It comes down to the general suckiness of SD cards. They are sensitive to temperature swings, have limited write cycles, and even when they are infrequently written to, can fail due to other reasons. I speak from experience.

How big temp swing? I have used SanDisk SD cards in for normal day use in cameras, cell phones, smartphones from -30°C to +25°C within minutes and not a single card has ever failed.

It is really hard to wear it out, I have seen this at work but we talk about log writes every second for 5-10years.

[faxloop]

Several people have mentioned that booting over HTTP is not feasible, introduces security issues etc. However, it is perfectly possible on x86 using a chain loader like iPXE [https://ipxe.org/].

Firstly, you build iPXE to include your NIC driver and an embedded config. In the config file, you can include a boot script that requests an IP over DHCP (locally) then downloads and boots from an image stored on a WAN HTTP server. Finally, you can burn iPXE to an EEPROM on your NIC so that all of this will work on a PC that has no permanent storage. On an SBC, I was hoping you could do something similar by writing the boot loader to the SD card. BTW, iPXE supports flow control and other kinds of logic so the boot script can be built to handle error conditions.

Since my SBC is ARM-based, iPXE won't work, and AFAIK, there is no equivalent for ARM. However, there is no reason why it shouldn't be possible to "roll my own" so to speak, which is what I would like to do.

P.S. I appreciate the suggestion to use a better SD card, and I will be sure to buy the best I can find (maybe an industrial SLC-based one) but I still have doubts about the longevity. All SD cards are tiny, cannot easily dissipate heat, and are not designed to act as the file system of a running machine.

Also, you need to consider that using an SD card as a computer file system, with lots of small random writes, and the inevitable write amplification caused by this, is a completely different use case to using it in a camera or cell phone where the writes are rare and when they do occur, are mostly large files written in one go (e.g. saving a photo or music file).

[tmomas]

@faxloop

you need to consider that using an SD card as a computer file system, with lots of small random writes

Where do you see "lots of small random writes"?

@psherman

OpenWrt doesn't write to your permanent storage except when you make changes

[lleachii]

@faxloop

However, it is perfectly possible on x86 using a chain loader like iPXE

@faxloop

However, there is no reason why it shouldn't be possible to "roll my own" so to speak, which is what I would like to do.

@lleachii

Also...you're describing "nested booting" (i.e. pass from one bootloader to another). I'm only aware of this in the i686/x86_64 types of processors.

Except that part...

@faxloop

and are not designed to act as the file system of a running machine.

Except those that are...

[flygarn12]

@faxloop

Also, you need to consider that using an SD card as a computer file system, with lots of small random writes, and the inevitable write amplification caused by this, is a completely different use case to using it in a camera or cell phone where the writes are rare and when they do occur, are mostly large files written in one go (e.g. saving a photo or music file).

I guess you mean my three RaspberryPi that run with SDXC cards and the Debian based OS actually writes system logs on the cards 24/7 and they still doesn’t fail over periods of years.

[eduperez]

I think you are creating a very complex solution, and very prone to failure...
Is a stock image really enough for your needs? Don't you need any post-install configuration?

[jdwl1o1]

If you’re planning to write your own loader download the uboot source and patch in wget with ssl.

Uboot is massively extensible and open source. While what you want to do isn’t to my liking if you want to build it then have at it.

[faxloop]

I'll look into this. Thanks.

Can you give me some pointers on what I'll need to modify on a stock image to make it bootable this way? Do I need to split the stock image into separate partition files and then serve one (maybe more?) of these to U-Boot over HTTP? Or are deeper modifications needed?

Also, there appear to be many U-Boot editions, patched to support specific hardware. Is it better to extract U-Boot for my device from an OpenWRT image or just take the mainline uboot source (my device is supported) and work from that?

[jdwl1o1]

Hi, you can boot directly from the initramfs images after downloading in u-boot, no need to break them apart.

u-boot isn't included with openwrt images (usually), you will need to build u-boot for your device specifically. If mainline u-boot supports it then start with that and then modify it to add the additional functionality you need.

To be clear, u-boot and openwrt are not related projects - you're not going to get much help here for building customised u-boots. From a quick search at least 1 person has tried to do this before;
GitHub - ProfFan/u-boot: u-boot with TCP/wget

[lleachii]

You know you just told the OP to build a whole image that can one day be as vulnerable as the problem the OP tried to "solve"...now they want your help to append wget into it...

@jdwl1o1

While what you want to do isn’t to my liking if you want to build it then have at it.

@faxloop

I want to do this so I can have an easily updatable

I notice security is never mentioned.

@lleachii

@slh

automated image downloads can be seen as DoS attack against the download servers and may be blocked (do talk to the server maintainers first and get their buy-in, cache locally).

This is the point of TFTP.

@lleachii

e.g. someone wanted/had a company where they always provided up-to-date router software for their devices, bootstrapped upon each fresh boot

[jdwl1o1]

Yep, fully understand that. It’s the op’s device and their use case, if this is what they want to do then that is their decision.

As for security, definitely something I would consider in building something like this - but it’s not my project so who am I to judge.

[faxloop]

You mention U-Boot isn't included with OpenWRT images. When I flash an OpenWRT image to my SD card and then boot from it, where is the boot loader/U-Boot? My device has no permanent storage and will automatically look for something to boot from on the SD card.

[jdwl1o1]

It’s uboot doing that ‘auto booting’ from the sdcard.

It’s the bootrom built into the SOC.

I’d suggest you’ve got some studying to do on embedded systems boot processes.

[lleachii]

But the servers don't belong to them.

(It's an interesting point of view that when one runs a server - don't care how a client abuses it...interesting. Getting permission is better that asking for forgiveness...after all, the OpenWrt developers are just a Private Message away.)

[faxloop]

It's interesting that you assume that a) you know how exactly the solution will work when not even the OP does at this stage, b) you assume the solution is downloading images from public servers, when this has never been stated and the reverse was implied and c) you assume the solution, whatever it is, will cause undue load on said server.

All very interesting

[lleachii]

@faxloop

you assume the solution is downloading images from public servers, when this has never been stated

@faxloop

it will have to boot over the internet, most likely with HTTP

???

Are we in the same thread?

It was stated in Post No. 1...unless that's semantic games.

Why would one need to load images directly into thier partitions and execute...it doesn't take a rocket scientist to figure out what you're doing.

1 I'm actually curious why one would do such a thing and 2)...I'd like a copy of the software (likely required by its license).

@faxloop

you know how exactly the solution will work

I didnt know you were suggesting solutions that wouldn't work. Thats interesting too.

@faxloop

you assume the solution, whatever it is, will cause undue load on said server.

I'm not the poster that suggested that; but I defnatly agree this could be mass produced. Asking permission of the owner doesn't hurt either. I'm shocked such a suggestion got resistance.

BTW, you are the OP.