Building an LTE Access Point with a Raspberry Pi(snikt.net)
snikt.net
Building an LTE Access Point with a Raspberry Pi
https://snikt.net/blog/2019/06/22/building-an-lte-access-point-with-a-raspberry-pi/
68 comments
https://apple.stackexchange.com/questions/199163/how-does-io... seems to think it's in the wifi beacon itself for OS X.
No detection method appears to be present in Windows 10, it's all geared towards LTE modems integrated in the machine.
I really wish this had been standardised.
No detection method appears to be present in Windows 10, it's all geared towards LTE modems integrated in the machine.
I really wish this had been standardised.
Windows 10 appears to support one of the newer standards for announcing su h details in beacon
"Microsoft has defined a vendor extension to the 802.11 protocol."
https://docs.microsoft.com/en-us/windows-hardware/drivers/mo...
https://docs.microsoft.com/en-us/windows-hardware/drivers/mo...
It also supports at the very least WiFi Alliance's Passpoint, based on 802.11u.
One can also use traffic shaping (iptables and tc) to dry up large downloads:
https://unix.stackexchange.com/questions/229403/rate-limit-n...
As anyone aware of even better solutions than this?
https://unix.stackexchange.com/questions/229403/rate-limit-n...
As anyone aware of even better solutions than this?
For macOS you need to use an app like TripMode [1] or Little Snitch [2].
[1] https://www.tripmode.ch
[2] https://www.obdev.at/products/littlesnitch/
[1] https://www.tripmode.ch
[2] https://www.obdev.at/products/littlesnitch/
Non unlimited data SIM cards are very uncommon in Austria where the writer of this article is from.
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 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]
[1] https://www.crowdsupply.com/lime-micro/limesdr-mini
For anyone who is interested in setting up their own LTE base station (which can be legal, btw) consider the LimeSDR Mini [1]
[1] https://www.crowdsupply.com/lime-micro/limesdr-mini
Thanks for the link, lots of great stuff on that site.
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.
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.
Can you comment on Ethernet being more power hungry than Wifi? That's the first time I've heard that.
Ethernet usually requires isolation magnetics and transformers, while WiFi is basically just a wire sticking out of an RFIC.
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.
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.
Maybe I should have written that article. :)
That might be unique to the RPi hardware I used. It might not.
Maybe I should have written that article. :)
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.
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.
I was also disappointed. This is basically just the following two tutorials combined in one:
https://www.raspberrypi.org/documentation/installation/insta...
https://pimylifeup.com/raspberry-pi-wifi-bridge/
Secondly, I hoped it was about the using the LTE dongle in modem mode via vwdial (or similar) rather than in RNDIS/network interface mode.
https://www.raspberrypi.org/documentation/installation/insta...
https://pimylifeup.com/raspberry-pi-wifi-bridge/
Secondly, I hoped it was about the using the LTE dongle in modem mode via vwdial (or similar) rather than in RNDIS/network interface mode.
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...
Merely out of personal interest. It is interesting interacting with the modem more directly.
True. Using "Hilink" is easy mode. Using NCM (in this case) is slightly harder but saves you from double NAT.
E3372 can be reflashed to do this.
E3372 can be reflashed to do this.
AFAIK there is no easy way of flashing the most recent firmware (e.g. 21.326.62.00.55).
Doesn't need to be the newest one.
I know, but once you are on the newest one, it seems impossible to flash to switch to a different firmware.
Title is missleading, i was hoping for https://bellard.org/lte/ :(
yeah, likewise, I suddenly noticed it was just an access point, which seems a bit trivial to be hitting the #1 spot on HN.
But I might be bias, I'd really ike a CAT-M1 and NB-IOT base station
But I might be bias, I'd really ike a CAT-M1 and NB-IOT base station
I had hoped this was a howto for building an LTE booster.
I know the spectrum isn’t licensed for us, but wouldn’t it be great if someone figures out how to build a booster for those of us with a weak signal.
I know the spectrum isn’t licensed for us, but wouldn’t it be great if someone figures out how to build a booster for those of us with a weak signal.
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.
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.
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.
Ah, now I understand, thanks!
In case of E3372 you need to reflash. Not a big problem though.
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.
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.
https://www.gl-inet.com/products/gl-ar750s/
https://www.gl-inet.com/products/gl-ar750s/
So how does it work? I assume the LTE USB modem operates on T-Mobile frequencies, so does that mean it accepts all T-Mobile customers?
How's authentication done? How does T-Mobile permit you to use their frequencies?
How's authentication done? How does T-Mobile permit you to use their frequencies?
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.
Correct. If you were to create an actual “access point” you will have the FCC and other agencies knocking on your door within minutes.
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)
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)
Yes, we had the FCC (via FBI) knocking on our door within 30 minutes. This was about 10 years ago when we were doing research with an access point.
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?
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?
Within minutes? Seems optimistic.
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.
Here in the US, portions of the 900 MHz band are used for ISM uses. Hypothetically, could one deploy a LTE access point on LTE band 8?
What you're thinking of is called a base station.
https://discourse.criticalengineering.org/t/howto-gsm-base-s...
https://discourse.criticalengineering.org/t/howto-gsm-base-s...
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.
Holy grail stuff there. Would love that too.
You should checkout EspressoBin, which should be more suitable for this task. Hardware-Switch, WAN-Port and so on
It has horrible reviews (booting by itself etc.). Any better alternative?
Welcome to the wonderful world of ARM SBCs.
Those reviews may be for the earlier versions of the Espressobin.
I had good luck with the Turris Omnia which is based on the same platform.
There's also the Turris Mox coming out soon.
Those reviews may be for the earlier versions of the Espressobin.
I had good luck with the Turris Omnia which is based on the same platform.
There's also the Turris Mox coming out soon.
I've had decent luck with this: https://mikrotik.com/product/RBwAPR-2nD
+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.
Is there no need to do additional handling for hung modems/connections and safe reboots, or is all of that left as an exercise for the reader?
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."
True. I just didn't find that stuff very difficult. It almost never came up.
I don't know of an equivalent for other OSes, unfortunately.
[1]: https://www.lorier.net/docs/android-metered.html