• [cancellato]

  • Messaggio #437
  • Modificato

leoniDAM oppure avranno il supporto nativo (presumibilmente) a breve

Mah, questo IMHO è tutto da vedere, perché al momento AFAIK il problema è tutto Italiano e di un singolo ISP. Che priorità possa avere per i produttori è tutto da capire. Specialmente finché usano OS per i quali manca il supporto upstream per MAP-T.

simonebortolin ma alla fine map-t è IPoE

Fino ad un certo punto - MAP-T è pensato per inviare le informazioni necessarie alla configurazione della CPE via DHCP, ed è meno esoso di risorse lato ISP perché demanda parte del processo di traslazione alla CPE, che è il motivo per il quale la CPE deve avere a bordo il software necessario per gestirlo, senza il quale non funziona. Dal punto di vista della CPE è più esoso di risorse.

        [cancellato] Dal punto di vista della CPE è più esoso di risorse.

        Dal punto di vista delle risorse MAP-T o IPoE senza MAP-T è uguale a livello di risorse consumate... c'è principalmente solo NAT da fare e cambia l'intervallo di porte.

        Forse ti confondi con MAP-E

            simonebortolin Magari... ma non è così.

            Devi anche calcolare l'IP di destinazione e il nuovo IP sorgente (che non è un semplice packet->src = interface->ip4_addr) oltre a cambiare gli header del pacchetto per trasformarlo da IPv4 ad IPv6.

            Sono calcoli semplici che potrebbero essere svolti in hardware ma al momento non è così.

            Comunque prima di commentare sulle prestazioni aspetterei qualche test di qualcuno con router non x86... può essere che non sia nemmeno così male.

            Inoltre tutto questo riguarda solo IPv4

                edofullo Devi anche calcolare l'IP di destinazione e il nuovo IP sorgente (che non è un semplice packet->src = interface->ip4_addr) oltre a cambiare gli header del pacchetto per trasformarlo da IPv4 ad IPv6.

                Ah

                  @x_term
                  eccomi. Ti sarei molto grato se potessi darmi una mano nel capire quale modalità è quella più indicata per tenere (ripristinare nel mio caso, quando verrà il mio momento) lo sky hub per gestire la fonia e usare un altro router a valle. Provo a dirti a grandi linee la mia configurazione attuale, che è quella che vorrei mantenere una volta fatto il passaggio a map-t (ora sono in dual stack come quasi tutti):
                  AX86U, collegato direttamente all'ONT, abilitati DHCP, DDNS e UPNP (tutto il resto è disabilitato tipo qos etc), rete wifi (2,4 + 5 wifi6), collegato a uno switch alla porta lan 2,5gbit (a cui sono collegati altri oggetti, tipo un hd di rete, il gateway per le valvole termostatiche TADO, una nvidia shield tv etc...), lan1+lan2 in bonding con Nas synology, lan 3 xbox e lan 4 Firewalla (https://firewalla.com/products/firewalla-blue) su cui gira un server openvpn.
                  Mettiamo che domani mi passino a map-t, posto che così come sono adesso non funzionerebbe più nulla, ho due opzioni: 1) asus come router in cascata 2) asus come access point. Cercherò di imboscare nel mobile lo sky hub, ma vorrei continuare a gestire tutto l'ambaradam così com'è, disattivando il wifi dell'hub. Sono anche disposto a collegare la xbox direttamente allo sky hub, non mi interessa che sia in rete locale. Meglio router in cascata o access point?

                  • x_term ha risposto a questo messaggio

                    radagast82 dipende dalla tua esigenza di rete interna, che mi pare molto diversa dall'OP dell'altro thread dove si è originata la cosa. Usando la modalità AP

                    • la rete viene gestita dall'Hub, quindi DHCP, DNS e UPnP sono lì - può essere un bel fastidio se hai statici ecc
                    • non usi due firewall, quindi le porte le devi aprire sull'Hub
                    • non perdi IPv6

                    Se usi la modalità router

                    • hai un doppio NAT v4, devi quindi mettere l'Asus in DMZ e poi gestire tutto lì
                    • DHCP, DNS, ecc sono sull'Asus
                    • perdi IPv6

                    In entrambi i casi tuttavia la fonia sarà sempre gestita dall'Hub per il limite di una registrazione alla volta dell'account SIP.

                      così a naso credo mi convenga l'AP. Alla fine di indirizzi fissi ne ho giusto un paio (principalmente il nas e l'hd), una volta gestiti nello sky hub amen.
                      Perdere l'ipv6 tanto vale cambiare operatore...

                      9 giorni dopo

                      Ciao ragazzi, porto cattive notizie.

                      Ho provato a chiedere sul forum openwrt e ad ora non è possibile includere il prefisso IPv6 nella IA_PD Solicit di OpenWrt visto che il client DHCPv6 non lo supporta, viene quindi settato a zero.

                      Invece tutto funziona senza problemi su Mikrotik (che però non supporta MAP-T) come diceva correttamente @x_term, dove però è errata la descrizione sulla wiki, che specifica solo la lunghezza

                      Include a preferred prefix length.

                      Grazie alla magia dell'open source proverò a includerlo nei file di configurazione, ma non assicuro la riuscita 🤪

                      Ho una linea Sky in attivazione Mercoledì (sperando non vada KO) ed un Belkin RT3200 con OpenWRT da provare, anche a livello di performance.

                      Sembra che ci stiamo avventurando in terre inesplorate, vediamo se riusciremo ad avere una rete degna del 2021 🥰

                      Come sempre, vi faccio sapere 😉

                        Ma quando ufficialmente Sky farà il passaggio a MAP-T?

                          Gundam75 Alcuni hanno già sono già su MAP-T ma c'è la possibilità di tornare in dual stack.

                          Entro il 2022 dovrebbero disabilitare IPv4 sulla rete metro.

                            gandalf2016 Si, per l'università nell'hinterland milanese.

                            Mi serviva assolutamente una linea senza vincoli e ne ho approfittato, è da vedere se l'attivazione riuscirà però, i corrugati del telefono sono stati murati.

                            /OT

                              edofullo
                              Uhm non ho propriamente indagato, sai se è un problema del demone o solo di configurazione?
                              Da quel che ho visto ci dovrebbe già essere un parametro ma che ad oggi non può essere aggiornato.

                              Sarebbe da fare una variabile in /tmp/ che viene letta da netifd e che se presente prova a passare l'ultimo prefisso conosciuto.
                              Ovviamente se ti si spegne il modem lo vai a perdere, ma non cè molto da fare. Andresti ad usare un sacco di IO sulla flash se lo aggiorni ad ogni lease.

                              Se serve una mano batti un colpo. Io ho finito da poco di portare OpewnWRT sul mio Aircube AC, e sembrerebbe che finalmente ci sia il roaming funzionante.... il driver per il LED mi ha fatto perdere la vita...

                                  hitech95 Io ho finito da poco di portare OpewnWRT sul mio Aircube AC

                                  OT

                                  Se lo pubblichi da qualche parte mi fai un favore: l'interfaccia di 'sto coso è scandalosamente scarna (i driver per il wifi come vanno a prestazioni? Noti degradi?).

                                  /OT

                                      hitech95 sai se è un problema del demone o solo di configurazione?

                                      Demone, ho già patchato, non veniva proprio passato il parametro (era sempre zero) 😁

                                      Ora ho fatto in modo che il reqprefix possa prendere un prefisso IPv6 completo invece che solo la lunghezza.

                                      Se vuoi ti giro l'immagine x86 patchata, però ha ancora qualche problema di segfault sul release del prefisso che prima di giovedì non riesco a sistemare 😐

                                      Le modifiche a odhcp6c sono sul mio github, quelle ad OpenWRT (praticamente solo lo script dei parametri) le ho solo in locale.

                                      Dai miei test nel Lab con mikrotik e la config di default del DHCP server sembra si riesca ad ottenere il prefisso che si vuole a patto non sia in uso. Speriamo i server DHCP Sky siano (non) configurati nello stesso modo 🤞

                                      Con un po' di fortuna mercoledì mi attivano una linea Sky, ma non so se riuscirò a testare questa parte perché la compilazione per arm mi sta facendo penare.

                                        OT
                                        mark129

                                        Sto aspettando che la patch venga accettata. per ora:
                                        https://github.com/hitech95/openwrt/tree/aircube-ac-bb

                                        Sai compilarti un immagine?
                                        Altrimenti scrivimi su Telegram e ti passo la mia immagine.

                                        Non ho visto degradi, io lo uso solo come AP.
                                        Unica nota è che 64Mb di ram iniziano ad essere stretti ad OpenWRT

                                        /OT

                                            OT

                                            hitech95 Sai compilarti un immagine?

                                            Yep!

                                            hitech95 Non ho visto degradi, io lo uso solo come AP.

                                            E' già importante, e comunque pure io lo uso principalmente come AP.

                                            /OT

                                                scusate, ho appena fatto passaggio a sky wifi con fttc. avevo intenzione di usare fritzbox 7530 che ho già come modem principale. non potrò farlo o ho capito male?

                                                  DrCarter33 avevo intenzione di usare fritzbox 7530

                                                  Se lo metti in cascata al modem del provider. Se (se) con i prossimi aggiornamenti AVM renderà compatibile il Fritz con MAP-T allora la questione cambia.

                                                      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