This is what I just call my internet box, it's portable (16 x 9.6 x 5.5 cm) and meant to be carried around in a backpack or in the car. Its intended purpose is to provide internet access at any speed (slow or fast) and remain connected at home, work or while traveling while providing better range than a smartphone when connected to mobile networks and lower costs if slow internet access is sufficient by making use of certain networking tricks. Whatever way it has to get internet access, it is then shared through the Ethernet port.
Note that this is not my primary way to get internet access, I do have regular broadband at home. I use this box when I'm traveling or at work in the middle of nowhere, or whenever my broadband fails.
Physically the box contains one single-board computer, one adapter board exposing USB ports that the board physically has but doesn't otherwise have enough space to properly expose and one mobile (4G or related) modem. The box does not have any batteries and requires an external 5V DC power supply to work, which can be provided by a USB power bank like those used for charging smartphones while on the go.
Specifically, the box has the following components:
The box is fed 5V into the OrangePi's USB-C port which then distributes that same 5V through the rest of the system via its headers and short cables with Dupont connectors. The power passes through the USB adapter board and then reaches the modem via a flexible USB extender cable. The antenna output of the modem is then exposed to the outside using an extender SMA cable.
Sharp eyes will notice that the micro-HDMI output is not exposed, it's covered behind plastic. This box does not
need video output, any necessary direct debugging and non-network CLI usage is done via the on-board debug UART.
The image below has a better view of the boards, but the modem in the middle is a different model that has since been removed and replaced with the current one.
The image below shows the single-board computer and the USB board outside of the box, before they were fit inside. Note that the USB board is still rectangular. Two of the corners had to be trimmed later for it to fit in the box.
The single-board computer has a cheap 32 GB microSD card that is just there for the OS and software configurations, it doesn't have any music or multimedia.
The modem fits only one nano SIM (4FF) card, I have three different SIM cards depending on how much I want to pay and where I am. In preferred sorting (from most to least), these are what I use:
The first card is an IoT SIM card able to connect to hundreds of networks, including three different carriers in Mexico, at a large per-MB cost. The second card is just a regular SIM card for one carrier, the third card is for a MVNO tied to a network that is NOT covered by the first card. The main reason why I prefer the first card is that it provides generally better coverage and largely only charges per-MB, which means it's extremely cheap to use as long as I use very little mobile data.
The modem supports a large amount of 4G, 3G and 2G bands and configurations. The most commonly encountered bands where I live for 4G cell networks are: B4/B5/B7/B28/B66, all of them are FDD. For 3G, I've encountered bands UTRA 2 (PCS 1900) and 5 (850 MHz), band 5 being more popular on roads and certain rural locations. For 2G (as of now only supported by one operator, which is Telcel and is supported by the IoT SIM card I have) I've detected bands 850 and 1900 MHz.
Usually, for some reason, 3G has a greater range than 4G where the same tower transmits both, even if it is detected that LTE Band 5 and UTRA Band 5 (both being roughly 850 MHz, intended to pass through trees more easily) are present on the same cell tower.
The box has an SMA female port that connects directly to the ANT (SMA) port of the modem, it is possible to connect a compatible antenna directly on that port, or a magnetic mount adapter (with its corresponding RF cable) that is in turn attached to an actual antenna. The use of a magnetic mount adapter on the roof of a car greatly improves signal reception (up to 10 dB as sensed by the modem) compared to attaching the same antenna directly to the box itself inside of the car. In this setup, the box greatly outperforms any smartphone simply by virtue of its antenna being outside of the metal box a car roughly is, a smartphone cannot do this and remain usable at the same time.
The modem supports voice calls through the same USB port it uses for data as long as the SIM card (and its operator) supports voice calls (the IoT SIM I use doesn't, it's data-only), but despite it ostensibly supporting VoLTE, I have never been able to get it to work, it always drops to 3G. I have only recorded and played back pre-recorded sounds that I examine once the call is done as a proof of concept, but actually being able to make and receive calls for me to use likely requires programming skills I do not have as of now.
The OrangePi Zero3 supports 802.11b/g/n and 802.11n/ac out of the box without any adapters. As of now there is a small antenna inside of the box that connects directly to the MHF4 connector on the board. Unlike a Raspberry Pi, the OrangePi Zero3 does not have any built-in antennas directly on the board, and as of now, I want to fit an adapter that exposes a female RPSMA port outside of the box to be able to use any Wi-Fi antenna and greatly increase its range for Wi-Fi usecases. As one can deduce by the presence of only one connector and antenna, the Wi-Fi adapter on the computer only has one chain.
The board exposes a USB-C female port (with gadget functionality, not yet mastered by me), a female USB-A port and a Gigabit Ethernet port. The Ethernet port has been configured to share any internet currently in use by the board's operating system by providing a DHCP server, firewall rules for masquerading traffic and a Network Address Translator (NAT) to be able to route and connect on behalf of other devices in IPv4. The image below shows the ports.
USB-C on the left, female USB-A on the center, Ethernet on the right. The SMA port on top-left
internally goes to the modem.
The single-board computer runs a Debian image available from the OrangePi website. PPPD, iodine and minicom are the primary packages installed in the quest to be able to connect and get online in more places or at a lower cost.
PPPD is a software for establishing Point-to-Point Protocol connections and, among other things, being able to pass IP packets through. Originally intended for use in dial-up connections, PPP (and by extension pppd) has remained relevant in modern times due to the prevalence of PPPoE in some broadband ISPs and, most importantly for us, because most mobile modems emulate AT modems and PPP connections to be able to give as much control over the data connection as possible to the calling computer.
In the most usual setup, the computer calls the modem using a special number (*99#) that tells the modem to initialize the PPP connection, immediately causing the computer and the modem to negotiate and eventually causing the modem to grant the computer (the caller) the IP address already in possession by the modem (or, in case that the modem is attached to a 3G network, immediately starting a data connection, getting an IP address itself and then copying it and handing it to the computer). The computer will be granted network access (assuming the modem itself has) and it will be able to place IP connections and communicate as if it was the modem itself (that is, no NATs except those already in the cell core network). If the cell network mandates or suggests the use of specific DNS servers, those will be passed by the modem to the PPP caller (the computer) and, if configured to do so, used by said computer.
iodine is an IPv4 over DNS tunnel software. This is meant to be able to pass through firewalls that block or restrict regular IP traffic but let DNS work normally. This is a very common situation on captive portals, that is, websites configured by the network to pop up into your view to tell you that your internet access has been restricted for some reason, and they are commonly found in rural internet hotspots, airports and mobile networks. They all usually let DNS through, and if you have a domain name (even if not a TLD domain name) and a server/computer with a public IPv4 address (even if a dynamic IP address) then you can use iodine.
Since iodine is a tunnel, your traffic will break out off the server where you run iodined (the server side, provided in the same website and package). Also, iodine does not encrypt your traffic, so it can potentially be decoded and looked at with the right software, but encryption inside of the tunnel will mess up with the compression making your tunnel even slower, so just... don't telnet through an iodine tunnel. The tunnel will naturally be slow (expect it to fall under 56 kbps often) and it's dependent on latency and how you set it up, so naturally it takes some trial and error to get it working optimally.
minicom is a terminal emulator commonly used for accessing devices via serial ports, such as modems. The modems I use pretend to be (multiple) serial ports even when connected to the system via USB, minicom can be used to control them and run AT commands to tune what your modem does or run commands for it to do or stop doing things or just for signal readouts and cell network information. Once your modem has been properly set up, you leave minicom and then start ppp to use the internet.
Debian, at least as delivered for this system, comes with NetworkManger which greatly simplifies operations with network devices (and makes a few more harder), including sharing internet access and automatically searching and connecting to the strongest Wi-Fi network that's already stored or its password known of.
I have made a few scripts in Python (aided with AI because I don't know Python) and bash (which I do know) in order to more easily use the software mentioned above.
The box alone already does plenty enough, but it requires extra stuff to be useful. Primarily, if one is using cell networks, then a compatible antenna is required. Further, while it already shares the internet through its Ethernet port, it'd be way more convenient if it could share the internet wirelessly. Again, external equipment to the rescue.
I have three different types of antenna for the internet box. They are all SMA male and they directly screw on a SMA female coaxial connector.
One of them is a black ~17cm omni antenna with a stated gain of about... 9 dBi? At what frequency? Anyway, it came with the modem, it is stated to work from 700 to 2700 MHz, I consider it a decent baseline. Image is immediately below.
Then I have this slightly longer 19cm omni antenna, I bought it online and it only said "850-2700 MHz" but the gain is nowhere to be seen. But it does outperform the black antenna on bands 4 and 5 (2100 and 850 MHz respectively) by about 2 dB, which are the bands I find more often. I have yet to make a hard test comparing their performance in LTE band 28, which is another common band around here.
Finally there's my big Yagi antenna with a stated gain of 30 dB and frequency ranges 800-900 MHz and 1800-2100 MHz, bolted to a 20 meters long RG58 cable and meant to be on top of a telecomm tower to fly above most trees. The cable losses are astronomical but then again it's for sitting at a large height where it sees above trees and buildings. Also, it works decently on LTE band 28 despite supposedly not being designed for it. It is very much not portable, the bar with the elements has a length of about 150 centimeters, it is basically there for the day when my broadband fails at home.
For the short omni antennas I have this magnetic base that firmly pulls itself on any metallic surface and, depending on how the antenna is located (and how much surface it exposes against the wind) it can sustain a wind speed of up to 130 km/h (like a car moving at that speed) without tipping or sliding away when sitting on a car roof. It has a SMA female port on top (where the antenna is meant to screw on), and a one meter-long cable with an SMA male connector at the end, which screws onto the internet box's SMA female port.
This is what the magnetic base looks like with the white antenna attached on top.
The SMA male connector of the magnetic base goes on the SMA female port of the box
This is what it looks like once it's connected, now it's ready to receive RF signals
While getting internet via Ethernet is already good enough, it doesn't take a lot of effort to convert it into wireless convenience by using a Wi-Fi-capable access point or a router. The chosen device for this purpose is the MikroTik RB931-2nD (also known as hAP Mini) for two reasons:
In fact, the 5V input on the device is just Micro USB-B, which was used for nearly one decade as the charging port of most smartphones and thus compatible cables are widely available. Additionally, the device consumes very little power, averaging 0.3 A at 5 volts.
In general, properly configuring a MikroTik device is hard because it's pretty flexible and highly advanced for its price point, the same software present on this little device is present on carrier-grade models. Basically, the device was configured to do this:
Ports or interfaces attached to the same bridge can talk directly to each other without passing through any
firewall. The box is connected to a port part of the normal bridge and thus other ports and the Wi-Fi
network connected to that same bridge will be able to talk directly to the box. Devices connected to the
restricted bridge will have to pass through the firewall and face restrictions whenever they
want to talk to the box or the internet.
What this accomplishes broadly is that you are supposed to run a wire from the box's Ethernet port to the device's first port, which is labeled "Internet" but really it's just port 1. Now, there are two Wi-Fi networks coming out of the same device: one that is unrestricted and gives direct access to the box as if one was directly connected to it, and a restricted one that blocks nearly everything but WhatsApp and a few select protocols.
This second network is meant to connect Android devices since it is notoriously hard to fully control what they do even with extreme restrictions. The first network is for devices able to avoid using the internet without the user's deliberate actions, such as my personal laptop that has Debian and xfce4.
Now, powering the router itself is very easy, you just run a cable from the box's USB-A female port (the "normal" USB port) to the hAP Mini's power input using an off-the-shelf charging cable. At this point two cables will run from the box to the hAP Mini, one for power and the other for data.
For obvious reasons, both Wi-Fi networks are password-protected. Neither restricts access to the hAP Mini's management interface nor the box's SSH server used to manage what the box and its modem do.
The red Ethernet cable is connected to port 1. That's where the internet should be arriving into. The small black
cable on the bottom is the power cable, coming from a USB port on the box.
Regardless of the flexibility the operating system in the single-board computer offers, useful operation often requires a short list of possible configurations or operation modes. In this case, since the purpose is to get internet access, all configuration profiles revolve around this.
Note that in all cases, the MikroTik device never ever needs to change its configuration, so its presence in diagrams would be irrelevant and for this reason it's not visible on them.
This mode is pretty simple, the board just connects to an existing Wi-Fi access point, performs the usual NAT and firewall stuff it has to do to share internet at all, then shares it out its Ethernet port. It does not require iodine nor ppp, it behaves like a simple router. Couldn't get simpler than that. Whether the Wi-Fi AP is password-protected or not is irrelevant once we know said password, it's the same thing as far as we're concerned.
Packet flow from external devices is represented with that line that connects boxes one another.
This mode is slightly more complex but still very straightforward. The board connects to the modem itself via PPP, establishes the connection and treats it like its proper gateway. As usual, it performs the NAT and firewall stuff it has to do, then shares its internet access out its Ethernet port. It uses ppp, but otherwise it still behaves largely like a simple router. It is assumed that the cellular antenna is attached and that a valid SIM card is inserted in the modem.
The modem is a component external to the SBC but still within its control, which is why it has a different box color.
Here's when things get a little more complicated. iodine is a tunnel and requires a previously configured endpoint (running iodined) and doing so is outside of the scope of this document; that is, we assume it is already set up at this point. Physically, connecting to Wi-Fi stays the same, but this time there's a firewall that is away from our control and blocks our internet access: it is a captive portal. It won't let us connect normally using the bare IP protocol. Now, said network requires a properly functioning DNS recursive server that is itself allowed to use the Internet and accessible without restriction by guests even if they are blocked. We will talk to the internet through it knowing this fact, iodine is the software required for this to work out.
Assuming, once more, that the server's already properly set up and running, the SBC will create the iodine client process and talk to the available DNS server our SBC is allowed to talk to. Since DNS is not fully centralized but data is delegated to servers of the domain owner's choice, this means that even though iodine only ever talks to that one available DNS server, queries will be passed verbatim to the iodined server since the domain in use has been delegated to it and the Domain Name System has no option but to comply without even being aware that encoded data is passing through it.
Once the tunnel is established, it is exposed to the operating system as a new interface and now the IP engine can use it if the user wishes so by creating IP routes that pass through it. Any data that passes through the tunnel will be automatically encoded and decoded by the iodine process, and by virtue of being a tunnel, traffic will, IP-wise, spontaneously appear where the iodined server is, connections will pass through the network said server is connected to and under its IP address. Account for this if you intend to use specific resources that may be blocked from that network or public IP addresses managed by it. The original identity of your physical connection (where the iodine client is) will be lost. This will also introduce latency (as if the DNS system wasn't laggy enough by itself), but given the low performance of DNS-encoded IP tunnels, the latency increases are not a concern in the real world.
Note that the device-originated traffic passes inside of the iodine tunnel, which is why there's a thin line within
a thicker line, the thin line is the encapsulated traffic and the thick line is how iodine encoded it.
Conceptually, iodine doesn't work that differently from before when used in a cellular network. All traffic has to pass through the modem and cell network after all, but instead of passing through the captive portal itself (which is impossible), we again encode data as valid DNS queries so they instead pass right through the cell network's DNS server (which has unrestricted access to the internet), into the DNS system and then right to our iodined server which then decodes it to be handled normally as native IP packets right into the public Internet.
Most but not all cell networks put you in a captive portal if the SIM card you're using corresponds to a prepaid plan and you're out of credit and/or data. The fact you're being told you need to pay means it is impossible for them to further bill your abuse of their DNS server even though technically it's just data passing through their network. After some time without credit since the date your last plan or top-up expired, the cell network may just refuse to show you the captive portal at all, in that case it will be impossible to use iodine until you top-up again.
Much like in Wi-Fi, iodine ignores the captive portal (blocking the internet) and talks through the unrestricted
DNS server.