№42133[Quote]
Here's what you need to do:
Step 1: buy an old Linux Thinkpad, libre it w/ Coreboot, then install, say, Gentoo GNU/Linux w/ openrc daemon mode and Sway. Then turn it into a makeshift Linux server by taking 5 raspberry pi 5's, then plug them into a TP-Link JetStream T1500G-10TT via ethernet, and plug your laptop into it also. You could simply buy a Xeon server tower PC running Linux instead, but that tends to be on the expensive end. Use the ThinkPad as the control plane (running Osmo components) and use the Pis as data planes.
Step 2: buy an Ovrdrive USB flash drive and flash the LUKS2 decryption key to unlock the desktop, after using LUKS2 for FDE (Full Disk Encryption).
Step 3: take two LimeSDR minis w/ LMS7002M SDR transceiver and antennas for RF frontend - one for RX, one for TX. Plug it into your laptop. This'll connect your laptop to the cellular network.
Step 4: buy a sysmousim developer SIM card, pop it into a USB SIM reader, and plug it into your laptop to program it for your custom network. Sysmocom provides excellent open-source tooling (sysmodown, osmo-sim-tool) for programming SIMs. Ensure you get the right SIM toolkit (STK) profile for your network.
Step 5: then you'll need to run OsmoBTS — BTS implementation, OsmoBSC — BSC functionality, OsmoMSC — mobile switching, OsmoHLR — subscriber database, OsmoMGW — media gateway, OsmoTRX and Asterisk — optional SIP/VoIP integration. All over Linux. Running OsmoTRX + OsmoBTS + OsmoMSC + HLR + GNUNet on a laptop CPU is doable but tight. Consider dedicating one Pi to the radio stack (OsmoTRX/BTS) and another to the core network (MSC/BSC/HLR). GSM is highly sensitive to timing. Ensure your NTP service is accurate. Jitter will cause dropped calls and registration failures.
Step 6: pop your sysmousim into a Motorola C123 or C139 running OsmocomBB flashed onto it via laptop and USB cord and self-activate onto the network. Make sure you get the North American variants of the C123 or if using C139, verify the specific variant you're using, making sure that it comes w/ GSM850 support.
Step 7: make a BTS tower out of a 200+ ft tall pole, some scavenged 800W–1kW solar panels, a solar charge controller, maybe an inverter if your PAs don't use DC, 2x 12V 100Ah LiFePO4 batteries in series (24V system) or a 48V system, and high-gain directional antennas if you’re doing a point-to-point, or sector antennas if you’re doing omnidirectional but with massive gain. Will also need Power Amplifier (PA) (A DIY LDMOS amplifier (like those based on the MRF6S211 or L3Harris parts) or a commercial 2W–10W PA with good linearity), Low-Noise Amplifier (LNA), and proper duplexers/bandpass filters (need filtering to prevent the PA’s harmonics from frying the LNA and to prevent interference). Users of the network will still need a 2G Yagi antenna to place outside their house on the front porch for better reception. Make sure you use lightning protection, electrical safety, RF exposure and interference control for your BTS tower.
Step 8: now you can run the GPRS connection to self-host a custom BBS written in Python scripted as a GNUNet overlay w/ installation instructions as provided on your Tor website (hosted over Wifi). Use SSH instead of Telnet. And use IGMP Snooping and QoS (Quality of Service). QoS allows you to prioritize GSM signaling packets over bulk data transfers, ensuring calls don’t drop when someone is downloading a file from your BBS. GNUNet is a peer-to-peer framework. Integrating it with SMS is tricky. You’d likely use osmo-msc to send SMS messages containing links or hashes to content hosted on GNUNet FS. Clients would fetch the content via GNUNet CADET. GNUNet can be slow due to DHT lookups and encryption overhead. For a BBS, this is acceptable. For real-time chat, it’s too slow.
Now you can use GNUNet BBS for sending SMS/notifications to subscribers to your free network that are within range, and create messageboards or even attach files to sites (say, audio files, like OPUS or AMR-NB - native to GSM voice codecs) over GNUNet FS and SIP routing through GNUNet CADET. Now you just created a hacker network that doesn't keep logs, is encrypted w/ PGP, not stored on any cloud servers, and is completely open source and free!
Note: You’ll need osmo2mo or a custom Linux-USB-GSM stack. The LimeSDR is primarily a software-defined radio (SDR) for research, not a dedicated cellular modem. You’ll be writing or adapting drivers to talk to the GSM stack. It’s possible, but expect significant CPU overhead and latency.
Note 2: Will need a part 5 experimental radio license from the FCC to broadcast GSM.
№42137[Quote]
Also, implement a local Stratum 1/2 NTP server using a dedicated GPS receiver (such as a GPS-doled HAT or PPS source) connected directly to the node running OsmoTRX. Monitor system clock jitter using ntpq -p or chronyc sources to ensure offset remains well below the microsecond threshold. Insert sharply tuned bandpass filters and cavity duplexers corresponding strictly to your operating band (e.g., GSM 850 or PCS 1900) between the PA/LNA and your antennas. Always verify spectral cleanliness using a spectrum analyzer or RTL-SDR loopback before connecting to high-gain external antennas. Ground all tower masts, coaxial cable shields, and lightning arrestors to a dedicated earth ground rod. Ensure your solar charge controller and DC breakers are correctly rated for your peak amp draw to prevent thermal runaway.
№42146[Quote]
You can run GNUNet inside the OsmoGGSN container/namespace so all GPRS traffic automatically enters the GNUNet overlay. This should be good for security/privacy, provided you're not hosting the database itself over the BBS. To do this, you'll need to do the following three steps:
1.) Configure OsmoGGSN to use a dedicated network namespace
Create an isolated network namespace for the GPRS gateway so its traffic can be handled independently from the core network signaling.
Verification: Run sudo ip netns exec ggsn_ns ip addr to confirm the virtual interface is active inside the namespace.
2.) Establish a lightweight proxy bridge
Instead of running the raw GNUNet-VPN directly on the GTP tunnel (which causes MTU fragmentation), route mobile data through a local SOCKS or TCP proxy inside the namespace that forwards payloads into GNUNet CADET asynchronously.
Verification: Check proxy logs to ensure data packets are successfully translating into CADET channels without dropping TCP connections.
3.) Tune kernel parameters for GPRS latency
Adjust TCP window scaling and queue limits inside the namespace to handle the high latency and packet loss inherent in software-defined 2G links.
Verification: Run sudo ip netns exec ggsn_ns sysctl net.ipv4.tcp_window_scaling to verify the setting is applied.
№42150[Quote]
To bridge GNUNet bulletin board updates into standard cellular SMS notifications, you need a script running on your control plane that polls the GNUNet filing system (FS) or CADET channels for new posts and uses Osmocom's CLI tools to inject them as SMS text messages down to the Mobile Switching Center (osmo-msc).
Write a polling script to monitor GNUNet FS (Python / Bash)
Create a lightweight script that queries your local GNUNet peer for new content hashes or bulletin board updates using gnunet-fs or a CADET client.
Verification: Run the script manually in your terminal to ensure it successfully fetches the latest post metadata from the overlay without timing out.
2.) Interface with Osmo-MSC via VTY or SMPP (SMS Injection)
Use Osmocom's built-in VTY interface or an SMPP (Short Message Peer-to-Peer) connection to push the retrieved text out to target subscribers.
Verification: Check the osmo-msc terminal logs to confirm the transaction identifier processes the SMS dispatch request successfully.
3.) Automate triggers via Cron or a systemd service (Background Daemon)
Wrap your polling and injection logic into a continuous loop managed by systemd to keep subscribers updated automatically whenever a new file or thread drops onto the peer-to-peer network.
Verification: Run sudo systemctl status gnunet-sms-bridge to verify the daemon is actively running and processing updates.