Not mentioned in the article, but I'd also recommend force-setting DHCP Option 43 to "ANDROID_METERED" to let Android clients know you're on a metered connection (hotspot) instead of a normal landline-based WiFi network. [1] This inhibits some things like automatic updates.
I don't know of an equivalent for other OSes, unfortunately.
I don't with to diminish the author's work but there's nothing all that special about the LTE portion. From the perspective of the Pi it's just another interface/network.
This is more akin to building a basic consumer all-in-one router -- which I think actually sounds cooler.
So the pieces that this article puts together:
* Bridging the Pi's ethernet and wireless interface and setting up DHCP pointing to a forwarding DNS server on the bridge with dnsmasq.
* Setting up Linux IP forwarding and the iptables rules needed to perform NAT over the WAN.
* Setting up a wireless access point on the Pi with hostapd.
It really is super cool that for $35 and an hour you can have a functioning, albeit not super fast, router that's basically ready to be plugged into a modem and work.
This specific Huawei modem also works with the Pineapple (it is plug & play IIRC). Its also worth noting that some routers allow a USB modem as fallback (Fritz!Box IIRC).
For anyone who is interested in setting up their own LTE base station (which can be legal, btw) consider the LimeSDR Mini [1]
A lot of how-tos that involve raspberry pi’s networking are no longer relevant or are just confusing because it contains conflicting information specific to some version of raspian. It’s sort of like trying to give new Lts Ubuntu a static IP only to discover it’s been changed. It’s nice to see it all pieced together.
Yeah, I did this myself not long ago as part of a mobile office rig and ... I didn't write about it or share about it becuase it was mostly just putting USB male connectors into USB female connectors and sourcing the right kind of batteries to charge things.
Oh, and learning ethernet cables are a monstrous power draw and you're much better off using wifi for everything.
I mean, yeah it's cool to have. But I can't help but feel like it's a bit trivial.
It's not so much that the transformers consume more power than just radiating it into the air, but that Ethernet is not designed with power efficiency as a goal. Ethernet devices that need more power usually get it from PoE instead.
Without doing any analysis at all, I suspect the idle behaviour is a big difference; Wifi goes silent if there's no traffic, apart from AP beacons, but Ethernet continuously transmits "fast link pulses" every 16 miliseconds to maintain autonegotiation and detect connection lost.
Honestly I dunno why it was the case for me. What I know is that I thought I'd save power pushing pulses over copper rather than using a radio. I didn't. In fact it was consistently about 40% worse than wifi.
That might be unique to the RPi hardware I used. It might not.
The Pi does Ethernet with a seperate and pretty power hungry chip.
If the ethernet cable is disconnected, that chip mostly powers down.
I think it's a Pi related thing rather than being inherent to Ethernet. In fact, if I were to guess, the energy per bit per meter of ethernet is probably far far lower than WiFi.
When you're already behind 2 levels of NAT, adding one more probably doesn't do much harm... It's not like you're going to be punching many holes through it either way...
I did something similar with OpenWRT and a MikroTik box. It works fine. The interesting bits were getting OpenWRT to work on a then-unsupported device (it was very similar to other devices, though), picking a modem with good support for multiple US carriers, depending on the modem, disabling USB3 by taping over those pins, flashing carrier-specific firmware, and getting the modem to connect.
Then I went overboard and set up routing so bulk traffic (OS updates, backups) go over a slower DSL connection, while other traffic goes over LTE. And if LTE goes down, it switches to the DSL connection.
Your comment motivated me to check if I could make my home router fallback to my second connection (I flashed it with OpenWRT). After fiddling with using usb wifi dongle as second wan entry and looking over if any nearby electronic shop has usb lan adapters in stock, I discovered that my router has vlans and I can "rob" one switch port for second wan.
So I set up mwan3 and have more and more respect for what one can do with Openwrt and off-the-shelf router.
As for the Huawei stick, most of them support being switched to modem mode using usb-modeswitch. But I'd prefer the "virtual network interface" mode if I had the choice, usb-modeswitch and modem stuff isn't exactly the best documented thing on this planet.
What's the difference? From the sound of it, the VNI would be a USB device identifying itself as an ethernet adapter and usb-modeswitch does... mode switching, like the 'alternative protocol' thingy that USB3 can do?
The difference is that in VNI mode the stick runs its own OS including a router and other crap while in modem mode it directly passes through the modem to the host device, leading to better performance, working "server" connectivity (assuming you can get a publically routed IPv4 address from your provider, though) and less security issues as there is one stack less to worry about.
Read it hoping to find use of an SDR or direct use of LTE modem instead it’s basically what any Linux user would have to do to get a USB modem working.
For some reason doing anything a normal Linux user would do but on a raspberry pi is instant clickbait.
I have a iNet Slate, its effectively the same thing but a bit more purpose built and has a switch on the outside (which can be configured to do different things) that can turn on VPN so all connections are VPN'ed. It supports USB tethering and a USB modem. For the money, after you're done buying a case, you'd still need more ethernet ports, it probably doesn't work when borrowing local wifi.
This is not about hosting an LTE 'access point'. It's about creating a access point which uses an LTE uplink. I agree, the title is somewhat misleading.
I don't think their response time would be nearly that quick. All the stories about Stingrays would imply that this actually isn't very well policed (FCC enforcement is reactionary. The carriers could be proactive, but then would discover the Stingrays. And if carriers were complicit with Stingrays, then Stingrays themselves wouldn't be necessary).
I would also think the widespread deployment of legit femtocells would provide a decent cover.
But yes, it is generally illegal. (Though this hasn't stopped OpenBTS from being developed)
Sheesh! Do you care to share any more details? How dense of an area? How was it detected? If by "access point" you mean 2.4GHz, what was the actual problem?
It was a GSM antenna that registered with I think AT&Ts network in Philadelphia. It was part of a legitimate research project, so no charges or fines were placed on us.
Your description just makes me more curious! What do you mean by "GSM antenna" ?!
Should I really read that as you had a legitimate cell radio device, and just attached an unauthorized antenna? Or was the radio itself experimental/unapproved?
I've heard tales of cell towers having more or less automatic interference detection and the owners have a big incentive to let the FCC know. For other things, it's so rarely enforced or "self-policed" (like ham bands) that it's super rare for people to get busted, even with triangulization being what it is. Some kid here in NYC was trolling on the NYPD frequencies (analog FM still) and it took quite a while to track him down.
There are so many cops going around with stingrays I sort of doubt that the FCC can be too aggressive about this stuff. I'd guess that the interference would have to be relatively major for them to show up very fast.
The author mentions power consumption issues in the post. I've seen the same when running RPi access points. Definitely use a decent power brick if you're going this route.
I would be more interested if someone managed to build a GRE tunnel bonding solution with open source tools. Multiplexing a data stream over multiple LTE uplinks would be nice.
I'm with you, it is a nice presentation and will follow it. Yanno' if you could get the ARM version of pfSense on the pi this would eliminate the Huawei modem, Maybe.
+1 for Microtik. They have their weird problems but are cheap and generally fairly reliable for what you get. Have a bunch of their hardware around, all served me pretty well.
Usually you can just do this from the command line. With the right tuning Pi's boot quite fast, so I just used a Pi reboot and a 4g gateway with no battery to solve these issues.
To me, the resilience in having that stuff automated is the difference between "an access point" and "a computer that just happens to bridge connections."
I don't know of an equivalent for other OSes, unfortunately.
[1]: https://www.lorier.net/docs/android-metered.html