Sky WiFi passerà a MAP-T entro il 2021

gianry c'è qualche altro modem nativamente compatibile con map-t ?

Forse alcuni TPLink recenti.

gianry praticamente il proprio indirizzo wan è quindi condiviso con altri utenti ?

In NAT 1:16 si, in 1:1 no.

gianry e la sicurezza è garantita ?

Direi di si, ma non ho capito cosa intendi

Confermo la porta 22 è ok e raggiungibile, evidentemente prima sbagliavo qualcosa.

Per i flussi TCP/UDP comunque il problema che openwrt non si assegna l'indirizzo non si pone, basta fare DNAT sull'indirizzo del router lato LAN... porcheria ma funziona.

Con flussi non TCP/UDP forse si può fare la stessa cosa ma non so.

edofullo Confermo la porta 22 è ok e raggiungibile, evidentemente prima sbagliavo qualcosa.

Occhio che ultimamente la 22 con openwrt rompe parecchio.
Delle volte va delle volte no. Non so se ci sono regrtessioni o cosa.
Ma mi è capitato più volte su target diversi. Ad oggi sulla 21.01 non va. (o perlomeno sulla mia build x86 no)

Putroppo FWS non sembra andare d'accordo con le regole di Openwrt e IPv6 altrimenti si poteva vedere subito e in maniera semplice la configurazione per capire se si può otimizzare il tutto. Sky sembra che ai pacchetti v6 diretti a map t gli faccia saltare tutta la chain v6 e vada a fare direttamente la traduzione in v4:

+    /* Add POSTROUTING rule. */
+#if (IVI_KERNEL_SUPPORT) || (NAT46_KERNEL_SUPPORT)
+    /* bypass IPv6 firewall, let IPv4 firewall handle MAP-T packets */
+    fprintf(filter_fp, "-I wan2lan -d %s -j ACCEPT\n", ipV6address_str);
+#endif // (IVI_KERNEL_SUPPORT) || (NAT46_KERNEL_SUPPORT)
+END:

Ma quelel due target lan2wan e wan2lan mi fanno tanto pensare che sia uno stack acellerato HW.

hitech95 Sarebbe interessante capire se con un FPGA si possa creare un accelleratore,

Sicuramente, visto che è questo il modo nel quale l'hardware carrier esegue l'altra metà del giochino, ma stiamo parlando di apparati con vincoli di budget completamente diversi dalla CPE utente che costerà all'ingrosso ad un provider 30-50€.

hitech95 L'header v6 è già calcolato in HW in molti casi dalla NIC in questo caso dovrebbe essere il chip dello switch a farlo.

Sopravvaluti della grossa gli switch chip degli apparati... personalmente ho i miei dubbi che la parte switch possa fare qualsivoglia accelerazione hardware. Quel che avviene di accelerato è nel SoC, a quanto so.

edofullo Io ricordavo che le regole di firewall fossero processate in sequenza, finchè non se ne trova una che fa match.

Si spera esista la conntable Quel che dici è vero ma per il primo pacchetto del flusso, poi le informazioni rilevanti dovrebbero venir memorizzate nella tabella connessioni.

gianry Non per essere polemico, ma le risposte che cerchi sono in questa discussione.

edofullo Se vuoi chiedigli anche se è atteso il comportamento dei traceroute in IPv4 (usciti dalla parte MAP-T)... non so se loro o MAP-T semprerebbero filtrare gli ICMP TTL exceeded.

MAP-T funziona con i protocolli TCP e UDP.. ICMP non ha una "porta", quindi non può farti translation mi sa. Mi sfugge in questo momento però come faccia a funzionare l'ECHO all'host destinazione. Mmmmm...
EDIT: as usual, RTFM, bastava leggere.

L'ICMP ECHO funziona perché viene usato l'ID nella testata per individuare il range e quindi traslare v4-v6 e viceversa, ma gli errori TTL exhausted sono inviati unsolicited dall'host remoto, e come tali non possono avere un ID riconducibile mi sa all'host che ha mandato il pacchetto scaduto. La risposta per TTL exceeded contiene l'header IP del pacchetto originale e i primi 8 byte dell'header TCP/UDP imbustato, la porta sorgente ci sarebbe pure, ma a quanto pare non è stata implementata in hardware la traslazione di questi messaggi o vengono persi nella traslazione lato OpenWRT, servirebbe una cattura per saperlo @edofullo

[cancellato]
Patterson sulla conferenza RIPE ha detto che quel modulo era rotto e che hanno usato l'implementazione di NAT46 fatta da Andrew. Da quel che si è capito hanno aggiunto patch sopra per accellerare la cosa via HW.
Il fatto è che non so bene se entrabi gli step sono accelerati o meno.

[cancellato] La risposta per TTL exceeded contiene l'header IP del pacchetto originale e i primi 8 byte dell'header TCP/UDP imbustato, la porta sorgente ci sarebbe pure, ma a quanto pare non è stata implementata in hardware la traslazione di questi messaggi o vengono persi nella traslazione lato OpenWRT, servirebbe una cattura per saperlo @edofullo

Domani procedo.

gianry https://ipv6-test.com/ 101.56.x.x è 1:16, 101.58.x.x è 1:1.
Se attivi DMZ o Port Forwarding sull'hub ti dovrebbero passare ad 1:1, di certo ancora il servizio clienti non lo sa fare.

fl4co A chi invece interessa sperimentare sulla linea o semplicemente vuole qualche opzione in più, se cambiando modem si vede la banda dimezzata

Beh, basta che prende un router più potente... già lo doveva cambiare... tanto i fritz sono già sovrapprezzati di loro

hitech95 Il vero problema è il reflection che non genera le regole.

Reflection funziona, alla peggio si passa dal BR.

Intendo per accedere dall'esterno direttamente al router.

Domani se riesco faccio in un altro thread una guida "for dummies" per evitare alla gente di leggere 600 messaggi tecnici

hitech95 Ma questa è una tua deduzione o ne sei certo? Nelle slide c'era solo scritto che broadcom lo aveva modificato

Allora @hitech95 (ti ritaggo così ricevi la notifica)

Ho scaricato i sorgenti da: http://www1.sky.com/opensourcesoftware/SkyQ/SkyBroadbandHub/SkyBroadbandHub_downloads.html (non supera 1.3MB/s..)

Ho trovato solo l'implementazione ivi/cernec di broadcom:

Però sembrano essere datati quei sorgenti, risalgono al 31/01/20.
Probabilmente in una versione più aggiornata ci sarebbe anche l'implementazione nat46 di broadcom

handymenny Ma quel modulo è GPL? Si potrebbero chiedere i sorgenti in teoria?

Negli header dei file è specificata GPLv2 - anche perché nel readme dichiara che il codice è ispirato o contiene parti di altre librerie - una delle quali è proprio CERNET/MAP che è sicuramente GPLv2. Quindi sarebbero costretti a rilasciare il codice dietro richiesta di chi l'ha ricevuto - quindi tutti i possessori di uno SkyHub.

Poiché è comunque un lavoro derivato Andrew Yourtchenko non ne ha il completo copyright e quindi AFAIK non può fare dual-licensing closed source per Sky o altri.

handymenny
Il driver ivi contiene #include <linux/brcm_dll.h> il che mi fa pensare che qualcosa di accellerato ci sia...