TD-LTE Router In-Depth Comparison: AirMaster 3100V vs GreenPacket DT-350

Evaluating indoor TD-LTE desktop modems for Band 42 (3500 MHz) deployments requires comparing RF sensitivity, throughput stability under weak signal conditions, and hardware VoIP capabilities. Here is an empirical comparison between the AirMaster 3100V and the GreenPacket DT-350.

Tested Models: AirMaster 3100V (Firmware V2.0.0B31) • GreenPacket DT-350 (Unlocked Band 42 SIMs)

Key Findings and Benchmark Summary

Feature	AirMaster 3100V	GreenPacket DT-350
VoIP Hardware	No FXS RJ-11 port	Built-in SIP client & RJ-11 port
Wi-Fi Performance	802.11n 300Mbps	802.11n 300Mbps
Weak Signal Stability	Superior antenna gain (RSRP stability)	Moderate gain; benefits from external SMA antennas
Firmware Flexibility	Clean web management	Requires unlocking for full VoIP/APN menus

Recommendation: If telephone VoIP handset integration is required, the GreenPacket DT-350 is the clear choice. For raw RF reception in fringe coverage areas, the AirMaster 3100V delivers more consistent speeds.

How to Perform Path MTU Discovery on Linux and macOS (Ping and Tracepath)

Mismatched Maximum Transmission Unit (MTU) sizes across VPNs, tunnels (WireGuard, IPsec, PPPoE), and intermediate network links frequently cause silent TCP connection hangs and packet fragmentation issues. Testing your path's effective MTU using the "Don't Fragment" (DF) bit pinpoints the exact link threshold.

Formula: Total MTU = ICMP Payload Size + 28 bytes (20 bytes IP header + 8 bytes ICMP header).

1. Path MTU Discovery on Linux

Use ping with -M do (enforce Don't Fragment) or tracepath:

# Ping with 1472 bytes payload (1472 + 28 = 1500 MTU)
ping -M do -s 1472 8.8.8.8

# If it reports "Frag needed and DF set", step down until packets pass:
ping -M do -s 1392 8.8.8.8 # (1392 + 28 = 1420 MTU, standard for WireGuard)

# Automatic MTU trace across intermediate hops:
tracepath 8.8.8.8

2. Path MTU Discovery on macOS

# On macOS, use -D to set DF bit:
ping -D -s 1472 8.8.8.8

How to Proxy Secure WebSockets (WSS) in a Subfolder with Apache mod_proxy_wstunnel

Routing secure WebSocket connections (wss://) originating from a specific URL subfolder (such as /websocket1) to a local backend daemon (running on an internal TCP port like 2085) requires configuring Apache's mod_proxy_wstunnel.

Prerequisites: Enable Apache modules: proxy, proxy_http, proxy_wstunnel, and rewrite.

Apache VirtualHost Configuration

# Enable proxy tunneling for WebSockets
RewriteEngine On

# Detect WebSocket upgrade request headers for /websocket1
RewriteCond %{REQUEST_URI} ^/websocket1 [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} upgrade [NC]
RewriteRule ^/websocket1/(.*)$ ws://127.0.0.1:2085/$1 [P,L]

# Normal HTTP proxy fallback (if needed):
ProxyPass /websocket1 http://127.0.0.1:2085/
ProxyPassReverse /websocket1 http://127.0.0.1:2085/

Reload Apache to apply:

sudo systemctl reload apache2

Building a Dedicated Jitsi Meet Video Conferencing Station on Raspberry Pi 4

Using a Raspberry Pi 4 connected directly to an HDMI living room TV with an external USB webcam creates a dedicated, affordable family video-conferencing terminal. However, running WebRTC in standard Chromium on ARM without optimizations often causes CPU throttling, audio noise, and meeting lag.

Optimal Hardware Choices: Raspberry Pi 4 (4GB) • Logitech C920 / C922 / C270 USB Webcam • Micro-HDMI to HDMI audio

Critical Hardware & Audio Points

• Microphone Input: The Raspberry Pi 4's 3.5mm onboard jack is output only (no microphone input pin). Connecting standard headset microphones requires either an external USB audio dongle or a webcam with integrated noise-cancelling microphones (e.g. Logitech C920).
• Audio Routing: Configure ALSA/PulseAudio to output conference sound through HDMI to your TV speakers while capturing voice from the USB webcam microphone.

Chromium Performance Optimizations for WebRTC

Launch Chromium in kiosk mode with hardware GPU acceleration flags:

chromium-browser --kiosk --start-fullscreen   --enable-accelerated-video-decode   --use-gl=egl   --ignore-gpu-blocklist   --autoplay-policy=no-user-gesture-required   "https://meet.jit.si/YourPrivateRoom#config.startWithVideoMuted=false"

How to Install Asterisk 18 and FreePBX 15 on Ubuntu (Raspberry Pi 4)

Running a full-featured IP-PBX telephony server on a Raspberry Pi 4 provides small offices and lab environments with an enterprise telephone system at negligible power consumption. This comprehensive guide covers compiling Asterisk 18 LTS with DAHDI/libpri and configuring the FreePBX 15 web administration portal on Ubuntu Server (ARM64).

Hardware: Raspberry Pi 4 (4GB / 8GB recommended) • OS: Ubuntu 20.04 LTS aarch64 • Stack: Asterisk 18 LTS, FreePBX 15, MariaDB, Node.js

1. Installing Build Prerequisites and MariaDB

sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install -y build-essential linux-headers-generic libssl-dev libncurses5-dev   libnewt-dev libxml2-dev linux-headers-$(uname -r) libsqlite3-dev uuid-dev   mariadb-server mariadb-client libjansson-dev libedit-dev sox libsox-fmt-all

# Configure database
sudo mysql_secure_installation

2. Compiling Asterisk 18 LTS

cd /usr/src
sudo wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-18-current.tar.gz
sudo tar -zxf asterisk-18-current.tar.gz
cd asterisk-18.*

sudo contrib/scripts/get_mp3_source.sh
sudo contrib/scripts/install_prereq install

sudo ./configure --with-pjproject-bundled --with-jansson-bundled
sudo make menuselect.makeopts
sudo menuselect/menuselect --enable format_mp3 menuselect.makeopts
sudo make -j$(nproc)
sudo make install
sudo make samples
sudo make config
sudo ldconfig

3. Installing FreePBX 15

Install Node.js, Apache, PHP modules, and run the FreePBX install script pointing to Asterisk:

cd /usr/src
sudo wget http://mirror.freepbx.org/modules/packages/freepbx/freepbx-15.0-latest.tgz
sudo tar -zxf freepbx-15.0-latest.tgz
cd freepbx
sudo ./install -n