Device to act as a WiFI hotspot and (small) web server for classroom use?

Hardware Questions and Recommendations
1

Hello.

I work for a small non-profit organization that supplies WiFi hotspots and sets of Android devices (with our own open-source reading software on them) to classrooms in developing countries. Currently, we're using off-the-shelf consumer WiFi routers as the hotspots to provide network connectivity, but for numerous reasons, we've decided these aren't good enough.

Some of the reasons include:

  • No ability to install our own software onto the routers. We want to run a small web server on each router, and have each router pull a set of OPDS feeds and EPUB files (using rsync) from sets of servers hosted in the US each time the router sees there's network connectivity. We'd also like to run a few small bespoke internal services such as collecting analytics and providing book search results over a REST API.

  • No ability (in the models we use) to run something like a small Squid cache. We're using a mobile fleet deployment system to push updates to devices, but the network connectivity is poor to the point that most devices can't complete the upgrades before the connection is dropped. With a Squid cache on the hotspot, only one device has to be able to pull an APK file successfully and the rest of the devices get the cached copy.

  • No (or extremely limited) ability to whitelist traffic. Right now, network connectivity is low-bandwidth, very expensive, and has very low limits with regards to data usage. As much as it would be great to be able to allow each device to go on the internet freely, we can't afford one student deciding to go on YouTube and eating up the entire school's monthly bandwidth quota in an hour.

So I'm looking at options for switching the routers we use to a single-board-computer style arrangement. I'm not completely set on Pi-ish SBC, it's just that I would prefer not to buy an off-the-shelf consumer router because these are not explicitly sold as "You are supposed to put your own operating system on this". If we buy proprietary routers, install OpenWRT on them, and set up all of our processes and builds around them, and then the manufacturer brings out a new revision that allows only signed firmware... Oh dear, now we have to pick out and transition to a new device. I would much rather buy something that is open right from the start (modulo any binary drivers that might sadly be required) so that we can choose new models at our own pace.

Unfortunately, although I have around two decades of software development experience, open source, administration of UNIX/Linux/BSD servers, and the like... I have very little experience with these kinds of devices.

Given the requirements:

  • Provide DHCP to a classroom of 30+ Android devices with extremely light bandwidth requirements.
  • Provide a web server for serving rather small (< 10mb) static files.
  • Have the ability to run a few daily scripts including rsyncing content from remote servers.
  • Provide a Squid cache (or equivalent) for caching requests made to external servers for APK files.
  • Be possible to administer over SSH externally.

... Can someone recommend to me a device that would be sufficient for this onto which I can install OpenWRT (or failing that, just a plain Debian install or similar)?

We'd prefer to buy something that is as "conventional" as possible (if such a thing even exists) so that we have the option to switch to a similar device if necessary. Having a manufacturer that has produced more than one device and will likely keep producing devices for years is a strong plus. A kickstarter-funded project that might possibly maybe produce ten units this year wouldn't qualify. :slight_smile: We supply to many schools, and the number is constantly growing, so picking a model that's actually possible to buy would also be a strong plus (it was very difficult to get hold of Raspberry Pi Nanos in another project, for example - they were constantly out of stock everywhere).

Any help would be appreciated!

2

I’d recommend looking at something like the GL.iNet AR300M and a small USB stick for “active” storage (on-board flash has a limited lifespan in number of write cycles).

The versions with NAND flash added are probably more “future proof” with 128 MB of storage, but there is an incremental cost there. Also, SPI NAND, while supported on GL.iNet’s excellent firmware probably won’t be supported under “vanilla” OpenWrt until after v19 is released.

I suggest that over “no-name” brands in terms of build quality, OpenWrt compatibility (their firmware is presently 18.06 with additional enhancements) and mid- to long-term availability. Given the nature of your project and possibly moderate purchase volumes, you may wish to contact them directly.

They have other units as well. I am very happy with the both the AR300M-Lite and AR750S units I have of theirs.

3

These look good! I'm actually quite surprised at the price. One thing that does concern me: 128mb DDR2 doesn't sound like a lot. I've had some experience running OpenBSD in very small 128mb VMs under virtualization, and it's pretty painful. How come these devices can get away with so little memory? Don't forget that we do want to do a little more than just DHCP and routing...

4

Note that there is a lite version and a standard version.

5

128 MB is very reasonable for devices that don't run dual- or triple-radios on ath10k.

Here's an Archer C7v2 (similar SoC but with an off-chip 5 GHz wireless as well) running two APs (with multiple SSIDs on each), mesh routing for multiple VLANs, syslog-ng, and OpenSSH server, just for a baseline

jeff@office:~$ free
              total        used        free      shared  buff/cache   available
Mem:         124500       28796       74400         608       21304       60172
Swap:             0           0           0

Yes, I wouldn't run a desktop distro of any flavor with less than a couple GB these days, but OpenWrt has spent a lot of time trimming down things such as the init replacement and the main IPC bus to be much less memory and CPU hungry than their normal counterparts.

Edit: Yes, the AR300M-Lite is presently available as a cost-reduced version, but I understand it to be a limited run. For budgetary purposes, I'd look at the AR300M16 or AR300M.

6

You can test and develop a lot of these ideas on a desktop VM; attach a "dumb AP" to a dedicated Ethernet port to be the wifi. That AP could be anything, even a home router with stock firmware, since it's not doing anything other than wired to wifi conversion.

7

I was also looking for such a portable device for a similar project! Can it be confirmed that a 5V powered router would cut the job for:

  • running another USB drive
  • providing wireless access to 30 clients at most
  • uhttpd to work with 30 concurrent connections at most, pulling off a couple of simple html page concurrently (or other web servers perhaps?)

all at the same time? My scenario is as follows:

Nobody watches presentation nowadays but looks at their phone while the presentation is on going. So, why not instead get people to connect to a wireless network with no internet access for the meanwhile. Then, a nodogsplash will redirect them to the presentation and just click "Next Page" when the presenter says click "Next". :stuck_out_tongue_winking_eye:

8

The Espressobin would be a good device to run the software, has no wifi, and the v5 has no case. People have reported thermal issues with the v7... so it's maybe not ideal.

For the moment, the WRT32x seems to be the best thing going in terms of muscle and connectivity. I think that Linksys isn't likely to put out several hardware revs on this board slipping under your radar, but basically anything you choose is going to need a big volume commitment to ensure you have long term availability, the world of routers and dev boards seems to turn over pretty quickly.

9

Ok, sounds good. I'd still like to review other options, but the GL.iNet devices are currently in the lead position.

There's nothing that GL.iNet make that's expensive as what we're using now. :smile:

10

@io7m: A similar system I did on a commercial basis, for a 1Mio+ city in Middle Americas, using movingcom routers. Because also used in public transportation, as mobile hotspots. As a lower cost device we are now switching to ZBT-WE1026-5G devices. Running captive portal, squid, nginx (incl. PHP) serving local content (also e-learning; lessons developed in coop with a local university) and a few more services for management/statistics, incl. rsync. You might send me a PM, in case of interest.

11

I think you overestimate what a proxy (in general, or squid in particular) can do in a world of https-everywhere. Proxies can't cache encrypted ressources (as in apks downloaded via https, or windows updates, or …), they can't do effective filtering or monitoring (aside from very generic quota reporting, fairly blunt IP/ host logging (the deep URL/ server paths are already encrypted)), unless you control all clients as well and force your MITM/ intercepting CA on their devices. Keeping whitelists/ blacklists up to date is not easy, just looks at Russias's fight against telegram as an inspiration.

Unless you move to modern multi-core ARM devices of the medium performance (and price) range, their CPU power and I/O performance over USB will be rather limited, probably better than the WAN links you might be dealing with, but 3-5/6 MByte/s is around the expected USB I/O troughput for most mips designs on an otherwise idle device. This worsens, a lot, with many concurrent accesses, especially if you also have multiple additional services (rsync is very CPU and I/O intense, squid will be as well in for classroom sized services), which will also bring CPU and RAM of the cheap crop of routers to their limits.

12

"simple" squid-cache is only useful for http-objects, in this respect you are correct. But lessons need not to be accessed via https, so lessons can be cached by squid. Besides APKs which are fetched from private http-resources.
For use in classroom environment, installation of special certs in the users devices might be reasonable, to allow decryption/caching of https-objects.
(Although I would not recommend, because of the complicated setup, which not even works for all sites/browsers.)
However, squid also can be used as a proxy for some "tricks". Not only for easy bandwidth sharing via "delay-pools".
rsync might be used during nightshift only for updates. Because it is unlikely to have lessons at 3am.
General critics do not necessarily apply to the usage case in question.

13

I subscibed to this topic because I'm interested in what shakes out.
I'll try to offer some comments based on similar efforts with much older HW:

One thing that does concern me: 128mb DDR2

my old creaky Netgear WNDR3800s https://openwrt.org/toh/netgear/wndr3800
have 128MB of RAM, and it is suprizing what they CAN DO with so little. installing a bit of python magic can momentarily saturate the cpu, but it will work.
I even added external 1GB swap files, but he never uses it.
I'm not suggesting this kind of device, merely that establishes the long-running baseline of what I perceive to be the '4mb flash' openWRT experience

my intermediate Netgear WNDR4700 https://openwrt.org/toh/netgear/wndr4700
had a beefier 1000Mhz cpu and 256MB, and I REALLY tried to push it,
installing nginx, mysql, php, perl, python, wordpress, and whatnot.
It provided excellent 55MB/sec network and disk performance (like samba 3.x) and
It provided "acceptable" response when serving static html content out of nginx's piehole .... however
once I upped the ante with wordpress extensions and dynamic php-driven content it fell down flat and struggled to keep up
Moreover the 4700 has a FAN, which always irked me and my attempt to replace it with a whisper-quiet mod... yes it died / i killed it on the operating table.

one more application tip, since you say you intend to manage your remote devices over ssh: openssh version 7.4 was the last to support arcfour cipher. arcfour really has superior performance on MIPS cpus. openssh developers ASSUME everbody uses Intel core i357 cpus, which favor/default/require aes since openssh 7.7/.8/.9. Performance goes in the toilet, and refuses to talk with arcfour-speaking legacy/older boxes. (However, core i7 to core i7 ssh endpoints with aes-acceleration run at wirespeed... . . . not even Xeon can do that). I dont use the dropbeard.

This year I am evaluating buying slightly -newer modern HW (Linksys venom or rango)
vs ditching MIPS entirely in favor of;

A) intel celeron / atom-by-any-other-name. The J4100/J4200 cpus appear to be the most current and capabile, but power requirements are up there compared to aarch/arm.

B) aarch64 with a rockchip rk3288 or rk3399 cpu. The cherry-pick of these devices have 4GB of RAM and 64GB of eMMC, gigabit ethernet and USB 3.0 -- IF you know what you're buying. Most the guys on Youtube who review SBCs have half-a-dozen also-rans in their drawer.
in my experience running heavily web-centric applications, Docker, webdav ~ has honestly been very pleasing on the rk3288
I lost an entire day of my life looking at the friendlyarm NanoPC-TC4, and all the accessories (& 4-port SATA hat!)

https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=225
and how to build openWRT for it:
http://wiki.friendlyarm.com/wiki/index.php/How_to_Build_OpenWrt

however both the aarch64 + atom device types above suffer from:

- short and random product lifecycles from erratic Chinese suppliers who crank out new boards every quarter.  I want lifecycles measured in years.
- random NICs from Realtek Atheros Broadcom Ralink or whoever which may or may not be supported by openWRT -proper releases. You will come to live and breathe snapshot releases, and ultimately build your own kernel and scrape firmware from the underside of garbage cans (I wonder if this will work...)  I'm still bleeding from building my own realtek driver+kernel modules  from the fifth git repo in this Quest.

good luck in making something which goes "above and beyond" router/packet functions! I find it fun.

1 Like
14

Deploying your own PKI is risky here since the servers (routers) which must hold private keys will not be physically secure. So you would have a trusted CA on every student device and a good chance that someone could get hold of a trusted certificate and its key.

I think it is still true that if you configure Android to "install from untrusted sources" you can host a collection of .apk's anywhere.

1 Like
15

Will do! Thanks!

@reinerotto It appears that I'm not at a high enough "trust level" to be able to send PMs yet. Is there some other way I can contact you?

16

Not sure if you were referring to me, but in our case the only thing that would be accessed over HTTPS would be the APK files themselves. The Squid cache is actually the least important part of this whole system - the MDM we use is open source and we're hoping to get a modification made to it to allow fetching the APKs from a local server rather than the central MDM server. This would get rid of the need for the cache entirely because we could just rsync the APK files to the hotspots.

We'd never be blacklisting. In our case the whitelist would contain perhaps three domains. As soon as the network connectivity improved, we'd stop using whitelisting entirely (it's purely there as an emergency measure to try to preserve precious bandwidth from well-intentioned but unfortunate web site visits).

Yes, I did wonder about that. I've seen rsync consume gigabytes of memory for deeply nested directories.

17

this means you can't cache the APK. but it seems unlikely that https is critical here, why not share the APK over http?

rsync will require you to transfer all the files regardless of whether anyone uses them, caching will have you transfer files precisely when someone uses them. it seems much better. also the io and ram requirements of rsync you have already seen.

as far as whitelisting, provided you use explicit proxy config, you can whitelist domains using squid. it's actually great for managing policy on a domain basis. it can't filter URLs at the path level for https but it's not a big issue for you

18

That is definitely an option.

There are two parts to this: rsyncing the OPDS feeds and EPUB files, and rsyncing the APK files. The former we will definitely need to do because the hotspots provide a library service that needs to keep working even when the internet connection goes down - they need to store a complete copy of the library. The library is fairly frequently updated with new books and fixes to epub files. This ensures that the class can always read all of the books in the catalog despite not being able to connect to an external server. The latter is less important: The APK files are quite large, and quite infrequently updated so we could go either way, really: Serve from a local httpd, or cache requests made to external servers.

19

I'm not so convinced that rsync is required here, though I don't know all the details, my concern would be that if you insist on rsyncing the whole thing before it works you may never get to a place where it works, if your internet is intermittent, not reliable, and slow. With a cache setup for the books as well, the teacher connects while there's internet, downloads all 5-6 books for the week or whatever, and then they're all cached, so that the students have access... through time the cache naturally grows, and it's all content that was actually desired. It makes efficient use of the bandwidth and time you do have.

You might also consider "pre-loading" the cache by taking the device before shipment and plugging in a USB key that has a pre-loaded cache. Then squid only updates the cache as things get added or replaced with new versions.

20

Even on a fast server class multi-core x86 system with multiple GB of RAM and spinning rust in RAID setups, rsync (you can't rely on timestamps (no RTC), so checksumming required) takes heavy resource usage and 'ages' (with the according CPU and I/O cycles, but little WAN traffic) with deep directory structures and many (small) files.

Post scriptum: I'm not saying that you can't do these things, just that the results may not meet basic expectations deliverable by the hardware, even considering your particular environment in mind.