simonebortolin Mi chiedo come possono fare un flusso HW acellerato compatibile anche per MAP-E dalla tua descrizione...

Non ho guardato di preciso la RFC di MAP-E ma se non ricordo male è un semplice incapsulamento del frama v4 in v6. In tal caso non c'è SNAT ma solo uno step di incapsulamento, taglio del frame v4 per farcelo stare nel v6. e invio. Nulla di complicato. Una lookup table in HW e un registro a scorrimento.

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

Sarebbe interessante capire se con un FPGA si possa creare un accelleratore, ma da quello che ho visto netfilter supporta solo da e verso una interfaccia (DSA o meno). Quindi nada. Forse con un FPGA che emula una NIC impostata come default route per il traffico v4 che fa il loopback dei frame v6 che poi uscirebbero dalla WAN. ma anche così facendo i frame passano sempre dalla CPU.

EDIT: dovrei provare a sperare che Felix o/e blogic mi rispondano ma la vedo molto difficile.
Il secondo ha smesso lo sviluppo di Openwrt in quanto ha iniziato a lavorare e si è messo "sotto".

      fl4co Il problema è che NON ci deve essere NESSUN incentivo ad usare il modem libero. è facoltà (e diritto) dell'utente usarlo, e l'operatore deve fornire un MODEM che sia comparabile ai modem liberi in commercio.

      Non vedo il senso di favore il modem libero, il modem libero deve essere equiparato al modem dell'operatore e dedicato principalmente ai geek. Altrimenti si fa solo peggio.

      Sai che facebook è intasato di gente che si lamenta che il proprio fritz è passato da 109.8 Mbps a 108.1 Mbps?

          simonebortolin Non vedo il senso di favore il modem libero, il modem libero deve essere equiparato al modem dell'operatore e dedicato principalmente ai geek. Altrimenti si fa solo peggio.

          Con il modem libero un sacco di gente ha avuto solo "rogne". Sono i due lati della medaglia.

            Qua ci sono un po' di "commit" riguardo a map-t:

            https://code.rdkcentral.com/r/q/map-t
            https://code.rdkcentral.com/r/q/author:abhishek.sivappa%2540sky.uk
            https://code.rdkcentral.com/r/q/SKYH4

            Magari c'è qualcosa di interessante da riciclare per openwrt

            Questo è interessante:
            https://code.rdkcentral.com/r/c/rdkb/components/opensource/ccsp/Utopia/+/58220/1/source/firewall/firewall.c

            #ifdef NAT46_KERNEL_SUPPORT
    // TCP MSS RULE - SKYH4-5123 - To improve IPv4 Downstream traffic performance
    fprintf(mangle_fp, "-A FORWARD -p tcp --tcp-flags SYN,RST SYN -o %s -j TCPMSS --set-mss %d\n", NAT46_INTERFACE, NAT46_CLAMP_MSS);
#endif //NAT46_KERNEL_SUPPORT

              simonebortolin

              in sù. Alcuni magari pure il gigabit pieno.

              Con MIPS32 dual core? Senza accellarazione hardware possono fare poco.

                  handymenny
                  Questo mi fa pensare che loro passano il traffico v4 direttamente all WANc he fa MAP-T in hw.
                  https://code.rdkcentral.com/r/plugins/gitiles/rdkb/components/opensource/ccsp/Utopia/+/refs/changes/20/58220/1/source/firewall/firewall.c#1078

                  Anche se questo è molto simile a OpenWRT

                  #ifdef FEATURE_MAPT
#define SYSEVENT_MAPT_CONFIG_FLAG "mapt_config_flag"
#define SYSEVENT_MAPT_IP_ADDRESS "mapt_ip_address"
#define MAPT_NAT_IPV4_POST_ROUTING_TABLE "postrouting_towan"
#define SYSEVENT_MAPT_RATIO "mapt_ratio"
#define SYSEVENT_MAPT_IPV6_ADDRESS "mapt_ipv6_address"
#define SYSEVENT_MAPT_PSID_OFFSET "mapt_psid_offset"
#define SYSEVENT_MAPT_PSID_VALUE "mapt_psid_value"
#define SYSEVENT_MAPT_PSID_LENGTH "mapt_psid_length"
#define ETH_MESH_BRIDGE "br403"
#if defined(NAT46_KERNEL_SUPPORT)
#define NAT46_INTERFACE "map0"
#define NAT46_CLAMP_MSS  1440
#endif //IVI_KERNEL_SUPPORT
BOOL isMAPTSet(void);
static int do_wan_nat_lan_clients_mapt(FILE *fp);
#ifdef FEATURE_MAPT_DEBUG
void logPrintMain(char* filename, int line, char *fmt,...);
#define LOG_PRINT_MAIN(...) logPrintMain(__FILE__, __LINE__, __VA_ARGS__ )
#endif
#endif //FEATURE_MAPT

                  Uhm...
                  https://code.rdkcentral.com/r/c/rdkb/components/opensource/ccsp/Utopia/+/58220

                  Molte modifiche sono relative alla Ui

                      handymenny Hai provato anche con iperf oltre al classico ookla?

                      No, non saprei dove provare.

                      Ho provato un paio di questi ma mi danno risultati infimi anche in IPv6 quindi penso ci sia qualcos'altro da qualche parte, sta sera non ho tempo per investigare.

                      hitech95 Ad oggi salvo forse broadcom (stando alla conferenza che ha tenuto Patterson) il passo di translation non viene fatto sulla CPU.

                      In che senso? E dove viene fatto?

                      hitech95 sono 4 core arm

                      due

                      hitech95 Domani chiedo al mitico Patterson di migrare. (ho finito le cose grosse per lavoro)

                      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.

                      hitech95 Bah è una lookup table in teoria non dovrebbe perdere troppo tempo nel "cercare" quegli algoritmi sono ben otimizzati.

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

                      hitech95 Cosa corretta altrimenti chi è in MAP 1:X con x != 1 non potrebbe raggiungere gli altri CPE.

                      Si ma per il NAT 1:1 è una gran rottura di cocomeri... forse si potrebbe mettere un bel if e in caso si sia in 1:1 assegnarlo?

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

                                    praticamente il proprio indirizzo wan è quindi condiviso con altri utenti ? e la sicurezza è garantita ?

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

                                      Vero my bad pensavo parlassimo delle regole di traslazione

                                      edofullo Si ma per il NAT 1:1 è una gran rottura di cocomeri... forse si potrebbe mettere un bel if e in caso si sia in 1:1 assegnarlo?

                                      Direttamente dallo sviluppatore di NAT46:

                                      Why does your interface not have an IP address?

                                      IP-addressing-wise this interface doesn’t exist - the MAP standard doesn’t split the port overload and v4-v6 translation… one in theory can assign an IP (which?) to it, but since conceptually it is a point to point interface to a “virtual magic translator box”, one don’t need address on it.

                                      So to me this looks very similar to a PPP tunnel and I really don't
                                      understand why you don't provide an IP to that interface. Is it
                                      because there is actually no gateway so the data would be stuck?

                                      it’s more that that address would need to come from somewhere - and be essentially bogus. Between dealing with a bogus address and none at all the latter option seemed more appealing.

                                      Well the firewall for sure knows the DNAT and SNAT v4 address to perform
                                      the NAPT operations, I'm not completely sure if you calculate it using the
                                      provided roules.

                                      You can not just assign the public IPv4 address that you have only
                                      part of. You do not own that address, you only own selected port
                                      ranges from it.

                                      If you assign it to an interface, you suddenly have to deal with the
                                      OS port allocation algorithms as well, etc.

                                          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 Occhio che ultimamente la 22 con openwrt rompe parecchio.
                                                      Delle volte va delle volte no. Non so se ci sono regrtessioni o cosa.

                                                      Prima avevo provato la 80 e non andava.

                                                      Ora ho fatto questio giochetto con la 22 e funziona, quindi di certo non è un problema lato Sky.

                                                      edofullo 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.

                                                          • [cancellato]

                                                          • Messaggio #586
                                                          • Modificato

                                                          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

                                                                      edofullo come faccio a sapere se a me è nat 1:16 o 1:1 ?

                                                                          edofullo 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.

                                                                          In che senso? Per il port forward?
                                                                          Il vero problema è il reflection che non genera le regole.

                                                                              gianry
                                                                              Vedi:

                                                                              hitech95 Ora considerando che per ora le pool v4 sono rispettate sappiamo che loro hanno una:
                                                                              101.60.0.0/13
                                                                              |--> 101.56.0.0/14 Pool Subscrivers
                                                                              |--> 101.56.0.0/15 Pool Subscrivers MAP-T 1:16
                                                                              |--> 101.58.0.0/15 Pool Subscrivers MAP-T 1:1
                                                                              |--> 101.60.0.0/14 Pool Infrastructure

                                                                                  • [cancellato]

                                                                                  • Messaggio #590

                                                                                  hitech95 Ad oggi salvo forse broadcom (stando alla conferenza che ha tenuto Patterson) il passo di translation non viene fatto sulla CPU

                                                                                  Ho trovato qui un riferimento fatto da Patterson qualche anno fa:

                                                                                  There are multiple vendors offering MAP-T Border Relays, and we've
                                                                                  been testing both OpenWRT-based CPEs as well as a custom CPE based on
                                                                                  the Broadcom BCM63138 SoC.
                                                                                  The Broadcom reference SDK comes with the CERNET kernel module and
                                                                                  userland tool, and supports hardware acceleration of MAP-T translated
                                                                                  flows with Broadcom's Runner fastpath.

                                                                                  Il modulo al quale fa riferimento è questo, anche se il codice non lo toccano più da 8 anni.

                                                                                      simonebortolin Quelli che si lamentano su Facebook non sono geek ma gente che vuole "il Fritz" perché è convinto che la connessione vada di più, non vogliono il modem libero per avere maggiore controllo.

                                                                                      Chi invece è interessato a sperimentare sulla linea o semplicemente vuole qualche opzione in più, se cambiando modem si vede la banda dimezzata, ci penserà due volte a rivolgersi a terze parti e quindi nei fatti il diritto al modem libero è compromesso. Non per colpa di Sky, eh, prima o poi la tecnologia progredirà e usciranno router più potenti e/o con accelerazione hardware.

                                                                                          Informativa privacy - Informativa cookie - Termini e condizioni - Regolamento - Disclaimer - 🏳️‍🌈
                                                                                          P.I. IT16712091004 - info@fibraclick.it

                                                                                          ♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile