/pol/ - Politically Incorrect

Will also need Power Amplifier (PA), Low-Noise Amplifier (LNA), and proper duplexers/bandpass filters.

Also, you will need to run your network through a custom BBS written in Python running as a GNUNet overlay over circuit-switched 2G SDR cellular. So that way you can send notifications and SMS to subscribers within the network. You can also create messageboards with instructions on your Tor site on how to install the network and open ports for it. So that way, you're using GNUNet CADET for SIP routing. So here's how it would work:

>User A (Pelion) dials User B on their Motorola C123.

>The C123 connects to the Local OpenBTS via the LimeSDR air interface (GSM TDMA).

>OpenBTS sees the call and hands it off to Asterisk.

>Asterisk looks up User B’s SIP URI. It finds that User B is reachable via a GNUnet CADET tunnel to Columbia.

>Asterisk opens a CADET tunnel to the Columbia Node.

>The tunnel is encrypted and peer-to-peer. No central server.

>The Columbia Node receives the SIP INVITE.

>It routes the call to the Local OpenBTS in Columbia.

>The local OpenBTS pages User B’s Motorola C123 over the GSM air interface.

>User B answers. The RTP (Real-time Transport Protocol) stream is then tunneled via CADET (or via direct IP if the overlay allows it) back to Pelion.

Here's what ChatGPT had to say:

Yes—the overall architecture is technically plausible, but there are a few important corrections. The interesting part is that you can separate the project into a conventional GSM access network and a completely independent, encrypted overlay for inter-site communications.

The architecture I'd use

┌─────────────────────────────┐

│ Hardened Gentoo / OpenRC │

│ Libre ThinkPad │

│ │

│ OsmoBTS / GSM stack │

│ Asterisk / SIP │

│ GNUnet │

│ Python BBS / provisioning │

└──────────────┬──────────────┘

│ USB

┌────▼─────┐

│ LimeSDR │

│ Mini │

└────┬─────┘

│ RF

filters / PA / duplexer

│

┌────▼─────┐

│ Antenna │

└──────────┘

GSM air interface GNUnet overlay

─────────────── ──────────────

Motorola C123 ──GSM──► BTS ──SIP/RTP──► GNUnet CADET

│

┌──────────┴──────────┐

│ │

Columbia node Other node

│ │

BTS BTS

│ │

C123 B C123 C

The GNUnet portion is particularly reasonable. CADET provides encrypted end-to-end channels between GNUnet peers, can route through intermediate peers, and provides authentication, confidentiality, integrity and replay protection. GNUnet even defines application types for conversation control and conversation audio, which makes the concept of carrying VoIP-related traffic over the overlay quite natural.

One major correction: OpenBTS vs. Osmocom

I wouldn't make OpenBTS the centerpiece.

>>13657158

For a modern experimental libre GSM network, I'd look more seriously at the Osmocom stack, particularly:

OsmoBTS — BTS implementation

OsmoBSC — BSC functionality

OsmoMSC — mobile switching

OsmoHLR — subscriber database

OsmoMGW — media gateway

Asterisk — optional SIP/VoIP integration

Osmocom continues to publish documentation for these components, including OsmoBTS and OsmoBSC.

That gives you much cleaner separation:

LimeSDR

│

OsmoBTS

│

OsmoBSC

│

OsmoMSC ───── OsmoHLR

│

OsmoMGW

│

Asterisk

│

GNUnet adapter

│

CADET

You could still experiment with OpenBTS, but I'd treat it as an alternative GSM implementation rather than assuming it's the best component for the whole system.

The SIM architecture needs one conceptual change

A SIM isn't really "activated onto the free network" merely by loading a network token into it.

>>13657159

You'd want your own closed subscriber system, where each SIM has credentials corresponding to your network's subscriber database.

Conceptually:

SIM

├── IMSI

├── authentication secret

└── GSM authentication parameters

↓

HLR

│

subscriber record

│

GSM authentication

↓

BTS

For an experimental network, you control both sides, so you can provision your own subscriber identities and authentication material.

A programmable/development SIM can therefore be useful, but the exact capabilities depend on the particular SIM/UICC and programming environment.

And your CADET idea can be made cleaner

>>13657161

Rather than having Asterisk itself understand all of GNUnet, I'd build a small SIP↔CADET gateway.

For example:

Pelion BTS

│

│ GSM

▼

OsmoMSC/MGW

│

│ SIP/RTP

▼

Asterisk

│

│ local gateway

▼

Python/C gateway

│

│ CADET

▼

Columbia GNUnet peer

│

▼

Asterisk

│

▼

OsmoMSC/MGW

│

▼

Columbia BTS

The gateway could maintain something like:

sip:1001@pelion.gsm

↓

GNUnet peer public key

↓

CADET application port

↓

sip:1002@columbia.gsm

That avoids trying to make SIP itself become the overlay routing protocol.

CADET identifies peers by their cryptographic peer identities and establishes channels to applications listening on a particular CADET port.

>>13657162

SMS/BBS is an especially interesting part

You could have:

Motorola C123

│

SMS

▼

GSM stack

│

▼

SMS gateway

│

▼

Python BBS

│

├── announcements

├── subscriber directory

├── message boards

├── documentation

└── node discovery

Then CADET can transport BBS synchronization between sites.

For example:

Pelion BBS

│

│ CADET

▼

Columbia BBS

│

▼

Charleston BBS

This is actually more interesting than simply using GNUnet as a fancy VPN: the GSM network becomes the local access layer while GNUnet becomes the decentralized inter-network layer.

The RF side is where I'd be much more conservative

>>13657163

Your LimeSDR Mini is the SDR, but it isn't itself equivalent to a complete cellular tower. The RF chain has to be engineered for the particular GSM band, power level, impedance, filtering, and regulatory environment.

Your conceptual chain is right:

LimeSDR

↓

appropriate RF filtering

↓

PA (if required)

↓

duplexer / diplexer where applicable

↓

feedline

↓

antenna

And on receive:

antenna

↓

filter

↓

LNA (if required)

↓

LimeSDR

But don't simply attach a high-power PA and Yagi and start transmitting. GSM occupies licensed cellular spectrum in many jurisdictions, and the permissible frequencies, power, emissions, antenna characteristics and authorization depend on the band and jurisdiction. For development, an RF shield box, attenuators, dummy loads, or an appropriately authorized experimental allocation is much safer than an outdoor tower.

Also, your statement that "the antennas on the LimeSDR Mini already provide that" needs correcting: the LimeSDR Mini is an SDR RF transceiver board; an actual usable external cellular installation still requires an appropriate antenna/RF path, and the board's connectors are not themselves a substitute for an outdoor cellular antenna.

The really neat part

If you abstract the system properly, GSM doesn't actually need to know that GNUnet exists.

>>13657164

You could make the stack:

APPLICATION

│

Python BBS / SIP

│

┌─────┴─────┐

│ Asterisk │

└─────┬─────┘

│

GNUnet adapter

│

CADET

│

┌────────────┴────────────┐

│ GNUnet transport layer │

└────────────┬────────────┘

│

Ethernet / Wi-Fi / Internet /

mesh radio / other transports

That's exactly where GNUnet's transport-agnostic design becomes valuable. CADET operates above the underlying peer connections and can route through other GNUnet peers rather than requiring every pair of sites to have direct connectivity.

So Pelion → Columbia doesn't necessarily mean Pelion has to directly reach Columbia:

Pelion

│

▼

Node A

│

▼

Node B

│

▼

Columbia

while CADET maintains the cryptographically protected logical channel.

The result would essentially be a small, privately administered GSM micro-network whose local cellular layer is Osmocom/LimeSDR and whose inter-site packet network is GNUnet. That's a much more interesting architecture than simply putting an ordinary GSM BTS on the Internet.

Available next action: Create a downloadable PDF file here in this chat containing the findings and recommendations above

>>13657153

I don't get the jargon

>>13657153

you're gonna go to jail if you take this outside

Can we pay you and your Indian buddies to do a half assed job of it , at an exorbitant rate?

>>13657209

The network is free for anyone to join.

Step 1: buy an old Thinkpad, libre it w/ Coreboot, then install Hardened Gentoo GNU/Linux w/ openrc and Sway/XFCE.

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: buy a LimeSDR mini w/ LMS7002M SDR transceiver and antennas for RF frontend. Plug it into your laptop. This'll serve as your cellular modem.

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.

Step 5: then you'll need to run OsmoBTS — BTS implementation, OsmoBSC — BSC functionality, OsmoMSC — mobile switching, OsmoHLR — subscriber database, OsmoMGW — media gateway and Asterisk — optional SIP/VoIP integration. All over Linux.

Step 6: pop your sysmousim into a Nokia 6310i (RH-17; can be patched up to support band 850) or a Nokia 6230 (RH-28; comes w/ GSM850 out the box) running OsmocomBB flashed onto it via laptop and USB cord and self-activate onto the network.

Step 7: make a BTS tower out of a 60-80 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). Let's take my state (South Carolina) for example. If I needed enough coverage for someone in Pelion to call someone in Columbia, I'd need 3x or 4x omnidirectional sector antennas all pointed 120° of each other to cover different regions so that way a good portion of the midlands and coastal areas would be covered and you would need to place it in Clarendon County (like Turbeville or Manning) because it's the highest elevated region in the area. And again, broadcast on band 850 because it has better range and reception than, say, band 1900. Nodes in the network will still need a 2G Yagi antenna to place outside their house on the front porch for better reception.

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). 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, is non-digital (circuit switched 2G over SDR), and is completely open source and free. And you now pissed off the FCC. Hope you can keep this as an offgrid option.

>>13657153

How about just… a regular ass radio?