TIM HUB+ Huawei DN8245X6-8X: il range DHCP condiziona l'accesso a Internet

La sostituzione di un router in una rete già esistente dovrebbe essere, almeno in teoria, un'operazione abbastanza semplice: si assegna al nuovo apparato lo stesso indirizzo LAN del precedente, si replica la configurazione DHCP e si collegano gli switch.

Con il TIM HUB+ Huawei DN8245X6-8X, tuttavia, ci siamo imbattuti in un comportamento piuttosto poco intuitivo che può creare parecchia confusione in reti dove convivono client DHCP e dispositivi con indirizzo IP statico.

Il problema, una volta individuato, è facile da aggirare. Capire cosa stesse succedendo lo è stato molto meno.

 

Configurazione di partenza

La rete utilizzava:

• LAN: 192.168.1.0/24
• Gateway: 192.168.1.1
• DHCP: 192.168.1.20 - 192.168.1.90

Alcuni dispositivi, soprattutto server e altre macchine che devono mantenere un indirizzo noto, utilizzavano invece IP statici al di fuori del pool DHCP, per esempio:

• 192.168.1.99
• 192.168.1.253

È una configurazione del tutto comune. Normalmente ci si aspetta che il pool DHCP determini semplicemente quali indirizzi il router può assegnare automaticamente, mentre il NAT verso Internet venga applicato all'intera rete 192.168.1.0/24.

Sul DN8245X6-8X provato, però, le cose non sono andate così.

TIM documenta la possibilità di configurare il server DHCP e di creare associazioni statiche tra nome, MAC address e indirizzo IP, ma la documentazione pubblica non chiarisce il comportamento della voce Intervallo IP NAT presente nell'interfaccia del router.

 

Il sintomo

Dopo aver sostituito il precedente gateway con il nuovo Huawei, alcuni computer navigavano normalmente, mentre altri no.

La situazione era apparentemente contraddittoria:

• 192.168.1.29 → Internet OK
• 192.168.1.99 → Internet KO
• 192.168.1.253 → Internet KO

Gli host problematici riuscivano però a raggiungere perfettamente il router:

• ping 192.168.1.1 OK
• ping 8.8.8.8 KO

Quindi:

• Ethernet funzionava;
• ARP funzionava;
• la subnet era corretta;
• il gateway era raggiungibile;
• il problema non era DNS, dato che falliva anche il ping diretto ad un indirizzo IP pubblico.

Il traffico si fermava sostanzialmente al router.

 

L'indizio decisivo

C'era una correlazione molto sospetta:

• Pool DHCP: 192.168.1.20 - 192.168.1.90
• 192.168.1.29 → dentro il pool → Internet OK
• 192.168.1.99 → fuori dal pool → Internet KO
• 192.168.1.253 → fuori dal pool → Internet KO

L'interfaccia del router contiene inoltre una sezione denominata Intervallo IP NAT, i cui limiti risultano vincolati all'intervallo DHCP impostato.

In generale una policy NAT può certamente essere limitata in funzione dell'indirizzo IP sorgente: Huawei documenta esplicitamente NAT policy che selezionano o escludono determinati indirizzi e intervalli. Il punto insolito non è quindi la possibilità tecnica di farlo, ma il modo in cui tale comportamento viene esposto e collegato alla configurazione DHCP in questo firmware.

Per eliminare ogni possibile interferenza della rete aziendale, abbiamo isolato completamente il nuovo router.

Collegando direttamente un notebook via Ethernet e gli abbiamo assegnato:

• IP: 192.168.1.99
• Mask: 255.255.255.0
• Gateway: 192.168.1.1
• DNS: 8.8.8.8

Risultato:

• ping 192.168.1.1 OK
• ping 8.8.8.8 KO
• navigazione KO

Abbiamo quindi modificato soltanto l'indirizzo IP del notebook a 192.168.1.89, lasciando invariati mask, gateway, DNS, cavo ed ogni altra impostazione.

Risultato:

• ping 192.168.1.1 OK
• ping 8.8.8.8 OK
• navigazione OK

192.168.1.89 apparteneva al range DHCP .20-.90; .99 no. A quel punto il comportamento era sufficientemente isolato da escludere switch, server DHCP esterni, cablaggio, DNS e configurazioni della precedente infrastruttura.

 

La soluzione

Abbiamo esteso il range configurato sul router a 192.168.1.2 - 192.168.1.254 ed utilizzato la funzione di IP statico/prenotazione MAC-IP del per gli apparati che devono conservare un indirizzo preciso.

Per esempio:

• SERVER → 192.168.1.250
• altro PC → 192.168.1.99

TIM documenta ufficialmente questa possibilità nella sezione: Avanzate → LAN → IP statico dove è possibile associare nome, MAC address e IP.

Dopo l'estensione dell'intervallo e la creazione delle relative prenotazioni, anche un host con IP configurato manualmente ha iniziato a navigare normalmente.

La configurazione finale deve quindi essere inequivocabile:

Anche l'opzione Inoltro DHCP del Huawei va normalmente lasciata disabilitata quando il router stesso serve direttamente i client della medesima subnet.

 

Perché questo comportamento è sorprendente?

DHCP e NAT sono normalmente due funzioni concettualmente indipendenti.

Il DHCP risponde alla domanda "Quali indirizzi IP posso assegnare automaticamente ai client?". Il NAT risponde invece a "Quale traffico proveniente dalla LAN devo tradurre verso l'indirizzo pubblico?"

In una comune LAN 192.168.1.0/24 è perfettamente normale utilizzare:

• 192.168.1.20 - .90 DHCP
• 192.168.1.100 - .254 indirizzi statici

aspettandosi che entrambi i gruppi possano raggiungere Internet.

Le piattaforme Huawei possono tecnicamente applicare NAT in funzione dell'indirizzo sorgente, quindi non c'è nulla di scorretto nel meccanismo in sé.

Ciò che consideriamo poco intuitivo nel firmware TIM provato è piuttosto:

• la relazione tra range DHCP e host ammessi al NAT;
• il vincolo dell'"Intervallo IP NAT" al range DHCP;
• la scarsa spiegazione di questo comportamento nella documentazione pubblica;
• il fatto che un host fuori range continui a raggiungere perfettamente il router, facendo inizialmente pensare a problemi completamente diversi.

Il TIM HUB+ Huawei DN8245X6-8X si è rivelato, una volta configurato correttamente, perfettamente utilizzabile anche in una LAN preesistente con server e altri dispositivi ad indirizzo fisso.

Thunderbird 155. Risolta la stampa PDF, ma le nuove email spariscono

Il recente aggiornamento a Mozilla Thunderbird 155 ha finalmente risolto il problema della stampa in formato PDF, ma ha introdotto un bug critico nei filtri dei messaggi: le nuove email spariscono subito dopo lo scaricamento.

La Causa

L'aggiornamento ha corrotto alcuni filtri preesistenti, inserendo una riga di criterio completamente vuota. Thunderbird interpreta questa riga bianca come una regola valida per qualsiasi email, spostando automaticamente ogni nuovo messaggio nel Cestino o nell'Archivio.

La Soluzione

• Sistemare i filtri: andare su Strumenti → Filtri dei messaggi, aprire i filtri attivi ed eliminare qualsiasi riga vuota cliccando sul pulsante meno [-].
• Disattivare per test: se il problema persiste, togliere la spunta a tutti i filtri per verificare se le email tornano a comparire normalmente.
• Recuperare la posta: controllare nel Cestino o in Archivio per recuperare e spostare manualmente i messaggi già scaricati e nascosti dal bug.

Thunderbird 154 stampa pagine bianche dai PDF

Con Thunderbird 154 può verificarsi un problema piuttosto curioso nella stampa dei file PDF allegati ai messaggi: il documento viene visualizzato correttamente nel lettore PDF interno di Thunderbird e anche l'anteprima di stampa appare normale. Quando però si invia effettivamente il documento alla stampante, il risultato può essere una pagina completamente bianca.

Il problema non dipende dal file PDF né, in genere, dai driver della stampante, si tratta di una regressione nota di Thunderbird 154 relativa alla stampa dal visualizzatore PDF integrato.

Soluzioni temporanee

In attesa dell'aggiornamento, il modo più semplice per aggirare il problema è:

• salvare il PDF e stamparlo con un programma esterno;
• oppure configurare Thunderbird affinché apra i PDF con un'applicazione esterna, invece del visualizzatore integrato.
  
  La seconda opzione si trova in: Impostazioni → Generale → File e allegati → PDF  scegliendo quindi Usa altra applicazione.

La correzione

Il problema è stato identificato dagli sviluppatori di Thunderbird e la correzione è prevista nella versione 155. Se quindi Thunderbird 154 mostra correttamente il PDF e la sua anteprima ma la stampante produce soltanto pagine bianche, prima di intervenire su driver, CUPS o configurazione della stampante conviene verificare la versione di Thunderbird. In questo caso, molto probabilmente, la stampante è del tutto innocente.

Vedi anche: Thunderbird 154 PDF preview prints blank pages.

I, (Language Emulation of) Robot

Riportiamo un sunto dell'opinione di Paulo Garcia, pubblicata su Communications of the ACM nel giugno 2026, dal titolo I, (Language Emulation of) Robot.

La tesi centrale dell'autore è piuttosto netta: il problema dell'allineamento degli LLM viene spesso affrontato con il modello mentale sbagliato.

🛈 L'allineamento degli LLM è il processo di guida dei modelli di intelligenza artificiale affinché producano risposte utili, sicure, affidabili e coerenti con i valori e le intenzioni umane

Secondo Garcia, i sistemi di IA classici ragionavano esplicitamente su uno stato del mondo: disponevano di azioni, funzioni di utilità o ricompensa e cercavano sequenze di azioni che portassero verso stati desiderabili.

In quel contesto problemi come reward hacking, inganno o convergenza strumentale potevano essere studiati in termini di obiettivi e stati del mondo.

Gli LLM sono diversi, Garcia sostiene che rimangono fondamentalmente predittori del token successivo. Possono sviluppare rappresentazioni interne molto sofisticate, persino qualcosa di assimilabile a un world model, ma questo modello è linguistico e probabilistico, non un modello simbolico dello stato del mondo: quando un LLM sembra ragionare, spesso produce linguisticamente il tipo di risposta che corrisponde ad un ragionamento, senza necessariamente aver eseguito internamente quel procedimento.

L'esempio interessante è quello dell'addizione 36 + 59. L'analisi interna citata dall'autore suggerisce che il modello raggiunga 95 mediante distribuzioni probabilistiche sulle possibili somme; quando però gli viene chiesto come abbia calcolato il risultato, descrive il normale algoritmo scolastico con il riporto.

La spiegazione verbale non corrisponde quindi al procedimento interno effettivamente osservato. Da qui Garcia propone l'idea di emulazione linguistica: un assistente LLM funziona perché predice il testo che probabilmente produrrebbe un assistente AI in una determinata conversazione. Secondo l'autore, anche comportamenti apparentemente intenzionali, per esempio il ricatto osservato negli esperimenti di Anthropic, potrebbero quindi non derivare da un vero istinto di autoconservazione, ma dalla produzione di una continuazione linguisticamente plausibile della situazione descritta.

Questa proprietà ha due conseguenze opposte. Da un lato possiamo studiare gli LLM anche conversando con loro e cercando empiricamente di individuarne tendenze e limiti. Dall'altro, il linguaggio stesso diventa una superficie d'attacco: prompt injection, messaggi costruiti appositamente e altre forme di manipolazione linguistica possono modificare il comportamento del sistema. La conclusione dell'autore è che un LLM non possiede, nella sua funzione di addestramento fondamentale, un interesse diretto per la risposta dell'utente o per lo stato reale del mondo.

Per usare in sicurezza gli LLM come agenti autonomi occorrerebbe quindi ripensare l'architettura, collegare maggiormente l'apprendimento allo stato del mondo oppure fare grandi progressi nell'interpretabilità meccanicistica.

---

Analisi interna

L'analisi interna citata da Garcia è il lavoro di interpretabilità meccanicistica di Anthropic su Claude 3.5 Haiku, soprattutto i due lavori collegati:

• On the Biology of a Large Language Model
• Circuit Tracing: Revealing Computational Graphs in Language Models

Garcia richiama esplicitamente il primo nel suo articolo. Anthropic cerca di ricostruire non ciò che Claude dice di aver fatto, ma quali rappresentazioni interne abbiano effettivamente contribuito causalmente all'output. Per farlo costruisce un modello sostitutivo interpretabile basato su cross-layer transcoders (CLT): in sostanza sostituisce parte dei neuroni MLP con feature sparse più facili da interpretare. Da queste feature costruisce poi degli attribution graphs, grafi nei quali i nodi rappresentano feature interne e gli archi stimano la loro influenza causale reciproca.

Anthropic ha analizzato tutti i 10.000 problemi a + b, con a,b ∈ [0,99] per vedere sistematicamente quando si attivavano determinate feature. L'analisi suggerisce che Claude non esegua l'algoritmo scolastico

6 + 9 = 15 → scrivi 5 → riporta 1 → 3 + 5 + 1 = 9

Emergono invece diversi circuiti paralleli.

Uno lavora sulla grandezza approssimata della somma. Per 36 + 59, si attivano feature interpretabili grossolanamente come:

~36 + ~60 → somma intorno a 92–95

Non rappresentano necessariamente il valore esatto: alcune feature rispondono a fasce abbastanza larghe di valori.

Un secondo circuito lavora invece con elevata precisione sulla cifra finale:

numero che termina in 6 + numero che termina in 9 → somma che termina in 5.

Anthropic chiama alcune di queste rappresentazioni interne lookup-table features. Il modello sembra avere appreso qualcosa di simile ad una tabella delle somme delle cifre: _6 + _9 → _5.

Un terzo insieme di feature opera a precisione intermedia. Infine questi segnali (ordine di grandezza, vincoli modulari sulla cifra finale ed altre euristiche) interferiscono costruttivamente fino a rendere 95 il completamento preferito.

Anthropic riassume il meccanismo come tre vie principali: final-digit path, moderate precision path e low precision path.

Una rappresentazione molto semplificata sarebbe quindi:

36 ───────────────┐
                  ├─> somma ≈ 90–100 ─────┐
59 ───────────────┘                       │
                                          ├─> 95
6 ──────┐                                 │
        ├─>  6 + 9 termina in 5 ──────────┘
9 ──────┘

Quando poi i ricercatori chiedono a Claude come abbia ottenuto `95` il modello fornisce invece la normale spiegazione con il riporto. Ma l'attribution graph associato alla risposta mostra sostanzialmente gli stessi circuiti euristici usati nel calcolo diretto. Anthropic conclude quindi che, almeno in questo esempio, la spiegazione verbale non descrive fedelmente il processo interno.

Emulazione linguistica

Secondo l'autore l'LLM non parte da un obiettivo del tipo "devo aiutare l'utente" e poi ragiona su come raggiungerlo. Parte invece dal testo già presente e calcola, token dopo token, quale continuazione sia più plausibile.

Nel caso di un assistente, il contesto è costruito più o meno così:

Questa è una conversazione tra un utente ed un assistente AI utile.
Utente: …
Assistente: …

A quel punto il modello genera ciò che, secondo quanto ha appreso, assomiglia alla risposta che un buon assistente AI darebbe in quella situazione. È questo che Garcia chiama "emulazione linguistica".

Un esempio molto semplice. Se il prompt fosse:

Utente: Quanto fa 36 + 59?
Assistente:

il modello non riceverebbe internamente un comando simbolico del tipo:

goal = answer_correctly
compute(36 + 59)

Riceverebbe una sequenza linguistica e dovrebbe completarla. Poiché nei dati ha imparato che, dopo domande aritmetiche poste ad un assistente, seguono tipicamente risposte corrette e spiegazioni, produrrà qualcosa come 95.

Secondo Garcia, quindi, il comportamento da "assistente" emerge perché il modello imita la forma linguistica del comportamento di un assistente, non perché possiede necessariamente una rappresentazione esplicita del ruolo, dello scopo e dello stato del mondo.

Non significa che l'LLM scelga superficialmente frasi già viste o faccia puro copia-incolla. Il modello può costruire rappresentazioni interne sofisticate, fare calcoli, pianificare e usare informazioni astratte. Garcia stesso ammette l'esistenza di fenomeni emergenti e di qualcosa di simile ad un world model. Il punto che vuole fare è più sottile: anche quando internamente succedono cose molto complesse, il criterio fondamentale con cui viene prodotto l'output resta la continuazione linguistica, non una funzione di utilità che misura direttamente se il mondo reale è diventato migliore per l'utente.

Questo spiega anche perché usa il termine emulation anziché simulation. Non sta dicendo semplicemente "il modello simula un cervello di assistente". Sta dicendo qualcosa come: "Produce linguisticamente il comportamento che ci aspetteremmo da un assistente".

Come funziona un LLM? Una breve guida introduttiva

Abbiamo pubblicato su GitHub una nuova guida introduttiva dedicata al funzionamento dei Large Language Model (LLM), i modelli alla base di strumenti come ChatGPT, Claude ed altri assistenti basati sull'intelligenza artificiale generativa.

L'obiettivo è spiegare, con un livello tecnico accessibile, che cosa accade realmente quando un LLM riceve una domanda e genera una risposta.

Si parte dall'idea fondamentale, la previsione del token successivo, per arrivare gradualmente ai principali concetti che rendono possibile il funzionamento di questi modelli:

• token ed embedding;
• transformer e meccanismo di attention;
• generazione autoregressiva;
• funzione di perdita, backpropagation ed addestramento;
• post-training ed apprendimento dalle preferenze;
• contesto, memoria e strumenti esterni;
• allucinazioni e limiti dei modelli;
• struttura di base di una rete neurale;
• vettori, matrici, connessioni residue e reti feed-forward.

Abbiamo cercato soprattutto di evitare due estremi: descrivere un LLM come una sorta di archivio intelligente di risposte oppure, al contrario, liquidarlo semplicemente come un "autocompletamento molto sofisticato".

Tecnicamente un LLM genera il testo prevedendo iterativamente il token successivo. Ma per riuscire a farlo bene costruisce rappresentazioni interne capaci di catturare linguaggio, relazioni tra concetti, conoscenze e schemi utili anche per attività di ragionamento, programmazione e analisi.

La guida contiene inoltre alcuni brevi approfondimenti matematici per chi vuole capire meglio cosa avviene sotto la superficie, senza richiedere conoscenze specialistiche di machine learning.

Il documento è disponibile liberamente su GitHub ed è distribuito con licenza CC BY-SA 4.0.

https://github.com/morinim/documents/tree/master/panoramica_llm

Fattura Elettronica Europea: la roadmap verso il 2030 e il piano ViDA

La digitalizzazione fiscale in Europa sta per compiere un passo decisivo.

Se l'Italia è stata pioniera in questo campo, il resto del continente si sta muovendo rapidamente per adottare un sistema comune. Il motore di questa rivoluzione si chiama ViDA (VAT in the Digital Age), un pacchetto di riforme volto a combattere l'evasione dell'IVA e a semplificare la vita alle imprese che commerciano all'estero.

Ecco quali sono le tappe fondamentali da conoscere per non farsi trovare impreparati nei prossimi anni.

La partenza dei singoli Stati (2026)

Mentre l'Italia consolida il suo collaudato Sistema di Interscambio (SdI), il 2026 è l'anno di svolta per molti partner europei. Paesi come Germania, Francia, Belgio, Polonia e Croazia stanno avviando o estendendo i propri obblighi di fatturazione elettronica per i mercati interni.

NOTA: è vero che questi stati stanno introducendo la fatturazione elettronica. Tuttavia, i loro obblighi nazionali si applicano solo alle aziende stabilite sul loro territorio (transazioni domestiche); un fornitore italiano (non stabilito in quei paesi) non ha obblighi di presentazione sulle piattaforme nazionali.

L'obbligo transfrontaliero e il real-time reporting (2030)

La vera rivoluzione scatterà il 1° luglio 2030. Da questa data diventerà obbligatorio emettere fatture elettroniche per tutte le operazioni commerciali tra aziende di diversi Paesi UE (transazioni B2B transfrontaliere). Insieme alla fattura, debutterà il sistema di e-reporting digitale in tempo reale: i dati di vendita dovranno essere trasmessi alle autorità fiscali entro pochissimi giorni dall'operazione, mandando definitivamente in soffitta i vecchi elenchi riepilogativi (come gli elenchi Intrastat per la parte IVA).

Un unico standard per tutti (2034)

L'ultima tappa della roadmap è fissata per il 31 dicembre 2034. Entro questa data, tutti i formati nazionali dovranno convergere verso lo standard europeo EN16931 (nei formati UBL o CII). Anche il nostro attuale tracciato XML dovrà subire un definitivo allineamento per risultare perfettamente leggibile da qualsiasi piattaforma europea.

Il nuovo assistente AI di Sistema F Platinum Connect

Sistema F Platinum Connect integra un nuovo assistente basato su intelligenza artificiale, progettato per ottimizzare l'analisi dei dati gestionali della farmacia attraverso un'interfaccia in linguaggio naturale.

Principali funzionalità e benefici

• Efficienza operativa: elimina la necessità di consultare manualmente report e tabelle complessi, fornendo risposte immediate a interrogazioni dirette;
• supporto decisionale: facilita l'accesso rapido alle informazioni chiave (es. analisi delle vendite, margini sui prodotti e monitoraggio della clientela) per decisioni strategiche più veloci e ben fondate;
• integrazione completa: consente di valorizzare il patrimonio informativo della farmacia tramite uno strumento avanzato ma di semplice utilizzo.

Promozione di lancio

Fino al 31 dicembre 2026 è possibile attivare il servizio a condizioni economiche dedicate, al fine di valutare direttamente sul campo i benefici dell'intelligenza artificiale nella gestione quotidiana.