Mese: Ottobre 2025

🧠 Come realizzare un tunnel SSH inverso per accedere a Home Assistant da remoto

Hai mai desiderato accedere alla tua domotica anche quando sei fuori casa? In questo articolo ti mostriamo come Marco, un appassionato di automazione domestica, ha configurato un tunnel SSH inverso per controllare Home Assistant in modo sicuro e senza esporre porte sensibili su internet.

🏠 Lo scenario

Marco ha un server Home Assistant installato su una rete locale con IP 192.168.88.1. Quando è in viaggio con il suo MacBook, collegato a una rete diversa (192.168.3.66), vuole comunque poter accedere all’interfaccia web di Home Assistant.

Per farlo, ha configurato il suo router con un DNS dinamico (hostddns.duckdns.org) e ha aperto la porta 6622, che viene inoltrata alla porta SSH del suo Mac.

🔐 La soluzione: tunnel SSH inverso

Sul server Home Assistant, Marco ha impostato questo comando:

ssh -N -R 8123:localhost:8123 -p 6622 marco@hostdmz.duckdns.org

Questo crea un tunnel sicuro che espone la porta 8123 (usata da Home Assistant) sul Mac remoto, rendendola accessibile come http://localhost:8123.

⚙️ Requisiti

  • Il file sshd_config sul Mac deve avere:
  • Il router deve inoltrare la porta 6622 verso la 22 del Mac
  • È consigliato l’uso di chiavi SSH per l’autenticazione automatica

🚀 Vantaggi

  • Nessuna esposizione diretta della porta 8123 su internet
  • Accesso sicuro e cifrato tramite SSH
  • Possibilità di automatizzare il tunnel all’avvio del sistema

🔋 Guida Pratica al SOC di Batterie in Parallelo con BMS

Se usi batterie LiFePO4 con BMS dedicati, sapere come calcolare il SOC (State of Charge) è fondamentale per monitorare quanta energia hai a disposizione. In questa guida, vediamo come funziona il SOC, come si calcola in parallelo, e come si distribuisce la corrente sotto carico.

📌 Cos’è il SOC?

Il SOC indica quanta energia è presente in una batteria rispetto alla sua capacità massima. È come il livello del serbatoio di carburante:

  • 100% SOC = batteria completamente carica
  • 50% SOC = metà carica
  • 0% SOC = batteria scarica (da evitare!)

✅ Formula semplificata:

SOC (%) = energia disponibile ÷ capacità totale × 100

🧮 Esempio 1: Batterie con cariche diverse

Hai due batterie in parallelo:

  • Batteria A: 100Ah al 75% → 75Ah disponibili
  • Batteria B: 50Ah al 50% → 25Ah disponibili
  • Capacità totale: 100 + 50 = 150Ah
  • Energia disponibile: 75 + 25 = 100Ah

👉 SOC totale = 100 ÷ 150 × 100 = 66,7%

🔋 Esempio 2: Batterie completamente cariche

  • Batteria A: 100Ah al 100%
  • Batteria B: 50Ah al 100%
  • Energia disponibile: 150Ah
  • Capacità totale: 150Ah

👉 SOC totale = 150 ÷ 150 × 100 = 100%

⚡ Esempio 3: Carico da 45A

Quando applichi un carico, la corrente si distribuisce in proporzione alla capacità:

  • Capacità totale = 100Ah + 50Ah = 150Ah
  • Carico totale = 45A

✅ Formula semplificata:

Corrente per ogni batteria = (capacità batteria ÷ capacità totale) × corrente totale

👉 Batteria A: 100 ÷ 150 × 45 = 30A 👉 Batteria B: 50 ÷ 150 × 45 = 15A

⚡ Esempio 4: Carico da 80A

Con un carico maggiore, la distribuzione resta proporzionale:

  • Capacità totale = 150Ah
  • Carico totale = 80A

👉 Batteria A: 100 ÷ 150 × 80 = 53,3A 👉 Batteria B: 50 ÷ 150 × 80 = 26,7A

📊 Entrambe si scaricano del 53,3% della loro capacità.

✅ Conclusione: Consigli pratici

  • Usa BMS compatibili per monitorare SOC e bilanciare le celle.
  • Non scaricare mai sotto il 20% per preservare la vita utile.
  • Il SOC totale si calcola come media proporzionale, non come valore minimo.
  • Distribuisci i carichi in base alla capacità per evitare squilibri.

🛠️ Risolvere i problemi di rete sulle schede Intel e1000/e1000e con uno script systemd persistente

Introduzione

Le schede di rete Intel basate sui driver e1000 ed e1000e sono molto diffuse nei server Linux e nei cluster Proxmox. Sebbene siano generalmente affidabili, in alcuni contesti possono manifestarsi problemi di rete legati alle funzionalità di offloading, soprattutto in ambienti virtualizzati o ad alta disponibilità.

Questi problemi includono:

  • Perdita di pacchetti
  • Congestione della coda di trasmissione
  • Blocchi temporanei delle VM
  • Messaggi kernel come NETDEV WATCHDOG o transmit queue timeout

🔍 Il problema: offload e instabilità

Le funzionalità di offloading (come TSO, GSO, GRO, RX/TX checksumming) sono pensate per migliorare le prestazioni, ma su alcune schede Intel possono causare instabilità, specialmente sotto carico o in presenza di bridge virtuali.

🛠️ La soluzione: uno script interattivo con systemd

https://community-scripts.github.io/ProxmoxVE/scripts?id=nic-offloading-fix

Per risolvere il problema in modo definitivo, è stato utilizzato uno script interattivo che:

  • Rileva automaticamente tutte le interfacce di rete basate su driver Intel e1000/e1000e
  • Disattiva le offload critiche tramite ethtool
  • Crea un servizio systemd dedicato per ciascuna interfaccia
  • Garantisce la persistenza della configurazione ad ogni riavvio
  • Fornisce comandi di verifica e log per auditing

⚙️ Cosa fa lo script

  1. Identifica le interfacce compatibili con i driver Intel
  2. Disattiva le seguenti funzionalità:
    • TSO (TCP Segmentation Offload)
    • GSO (Generic Segmentation Offload)
    • GRO (Generic Receive Offload)
    • RX/TX checksumming
  3. Crea un file .service in /etc/systemd/system/ per ogni interfaccia
  4. Abilita e avvia il servizio con systemctl
  5. Fornisce comandi di verifica (ethtool, systemctl status, journalctl) per confermare l’efficacia

✅ Risultato: rete stabile e cluster affidabile

Dopo l’applicazione dello script su tutti i nodi del cluster, i benefici sono stati immediati:

  • Nessun nuovo errore NETDEV WATCHDOG
  • Offload disattivati in modo persistente
  • Log di sistema puliti
  • Migrazioni HA fluide e senza freeze
  • Maggiore affidabilità sotto carico

📦 Compatibilità

Lo script è compatibile con:

  • Proxmox VE (tutte le versioni recenti)
  • Debian e derivati
  • Interfacce gestite da driver Intel e1000/e1000e
  • Ambienti virtualizzati con bridge e VLAN

Conclusione

Se stai gestendo un’infrastruttura Linux o Proxmox con schede di rete Intel, disattivare le offload in modo persistente può risolvere problemi critici di rete. Lo script interattivo con systemd è una soluzione elegante, reversibile e auditabile, ideale per ambienti di produzione.

🛠️ Risolvere i timeout di rete su schede Realtek r8169: il ruolo di ASPM

Introduzione

Se stai usando una scheda di rete Realtek r8169 su Linux (Debian, Proxmox, Ubuntu), potresti aver incontrato questo messaggio nel log di sistema:

Codice

NETDEV WATCHDOG: transmit queue 0 timed out
ASPM disabled on Tx timeout

Questo errore indica un problema critico di trasmissione che può causare instabilità di rete, perdita di pacchetti e reset del link. In questo articolo analizziamo la causa, il ruolo di ASPM e come risolvere il problema in modo permanente.

Cos’è ASPM?

ASPM (Active State Power Management) è una tecnologia PCI Express che riduce il consumo energetico dei dispositivi quando non sono attivamente in uso. Gestisce lo stato del link PCIe tra la scheda e il chipset, passando da:

  • L0: attivo
  • L1: inattivo ma pronto
  • L2: quasi spento

Su alcune schede Realtek, ASPM può interferire con la trasmissione, causando timeout e instabilità.

Sintomi del problema

  • Messaggi NETDEV WATCHDOG nel log kernel
  • Disconnessioni di rete intermittenti
  • Reset del link
  • Prestazioni degradate sotto carico

Soluzione passo-passo

1. Disattiva offload sulla scheda

bash

ethtool -K enp6s0 gso off gro off tso off tx off rx off

2. Crea un servizio systemd persistente

bash

cat <<EOF > /etc/systemd/system/disable-nic-offload-enp6s0.service
[Unit]
Description=Disable NIC offloading for Realtek r8169 interface enp6s0
After=network.target

[Service]
Type=oneshot
ExecStart=/sbin/ethtool -K enp6s0 gso off gro off tso off tx off rx off
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable disable-nic-offload-enp6s0.service
systemctl start disable-nic-offload-enp6s0.service

3. Disattiva ASPM via GRUB

Modifica /etc/default/grub:

bash

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pcie_aspm=off"

Poi:

bash

update-grub
reboot

Verifica post-modifica

Dopo il riavvio, controlla:

bash

ethtool -k enp6s0
journalctl -b | grep enp6s0

Se non compaiono nuovi NETDEV WATCHDOG, la scheda è stabilizzata.

Conclusione

Il problema dei timeout su Realtek r8169 è noto e può essere risolto disattivando ASPM e le offload. Questi interventi migliorano la stabilità di rete, soprattutto in ambienti server e cluster Proxmox.