dariuccio83 Allora sta sera provo anche io con Pixel 6 e Android 14, però il mio problema era che non si registrava nemmeno, quindi non saprei.
dariuccio83 Resta il fatto che Apple potrebbe risolvere facilmente per tutti abbassando l'MTU e invece...
Più che altro Sky dovrebbe non frammentare i pacchetti...
edofullo Più che altro Sky dovrebbe non frammentare i pacchetti...
Sicuro, però il Wi-Fi Calling è un servizio pensato per funzionare su qualsiasi rete Wi-Fi. Operatori di rete fissa difficoltosi ce ne saranno parecchi nel mondo, quindi è il produttore del device (Apple) che deve fare in modo che funzioni su più reti possibili. In questo caso basterebbe usare un MTU più conservativo anziché lasciarlo determinare al telefono ogni volta, e nel nostro caso il test fallisce. Nel log ho trovato una marea di questi errori:
errore 19:07:27.054636+0100 CommCenter Failed to set MTU with NEHelper: Invalid argument
default 19:07:27.054744+0100 CommCenter DATA.TechContext.1:1: #E startiPSecConnection: Virtuallnterface setMTU failed: 50000Update: oggi mi funziona solo con l’ePDG 151.58.176.144 (non col .129), bah…
dariuccio83 sta provando ad usare 50000 come MTU?
@dariuccio83 ho fatto solo qualche prova forzando prima 151.58.176.144 e poi 151.58.176.129 ma la situazione non cambia con Iliad (ossia chiamata che parte in VoWifi e poi fa fallback in VoLTE o 3G).
Poi però, non mi ricordo bene quale operazione ho fatto, se dopo aver riavviato il telefono o averlo messo in AirMode + attivato Wifi + disattivato AirMode ma sta di fatto che la chiamata VoWifi è andata correttamente (con il .129).
Stasera farò altre verifiche per capire bene quale combinazione ha avuto successo.
handymenny Esatto! Ovviamente non ci riesce…
trabattaro Un riavvio mi sembra il minimo in questi casi, altrimenti può ricordare l’IP dell’ultimo ePDG agganciato senza fare una nuova query DNS. Forse basta mettere modalità aereo ma nel dubbio…
Comunque a me oggi funziona tutto regolarmente con il .144
dariuccio83 Esatto! Ovviamente non ci riesce…
Allora forse prova a recuperare la MTU tramite IPv6, sarebbe interessante provarlo a disattivare
Secondo me o iOS fa qualcosa di strano, oppure c'è qualcosa che sta saltando. Sarebbe interessante vedere un pcap (lato router o AP) di un device dal momento dell'attach a quando lancia una chiamata in voWiFi.
in linea di massima in IPv4 (visto che l'IP del tunnel è v4), il workflow per il calcolo di PMTU è il seguente:
Dai pcap lato AP o router si dovrebbe vedere bene (non serve ispezionare il traffico dentro al tunnel).
50k di MTU (follia!) li vedi solo se ICMP 3 contiene quel valore nel payload, ma mi pare follia pura.
handymenny Non credo perché TechSettings è configurato in IPv4-only, comunque farò una prova…
nanomad iOS fa la sua parte. Secondo me parte da un valore volutamente irrealistico (50000) di default, ma lo script/helper che dovrebbe determinare quello corretto fallisce e rimane quello. Comunque anche nei casi in cui funziona l’ho visto settato a 2000. Si tratta comunque del tunnel interno. Con Wireshark ho visto pacchetti ESP al max da 1492 bytes. Appena posso comunque vedo che succede dall’attach…
Resta il fatto che la Path MTU Discovery su Sky Wifi non funziona correttamente. Probabilmente da qualche parte bloccano qualche pacchetto ICMP di troppo…
qualcuno ha provato la beta2 ? non vorrei che l'avessero disattivato (dato che ora lo uso, non vorrei privarmene)
cagnulein Certo, stiamo parlando della beta 2. Non capisco questa paura che venga disattivato. Questa volta c’è la configurazione specifica per TIM e W3, non funziona mica per caso con quella generica come con la 17.0.
la paura con apple ci sta sempre 
handymenny nanomad Allora ho disattivato IPv6 in LAN e ho fatto qualche cattura. Ho dovuto anche disassociare e riassociare la rete Wi-Fi sul telefono e sono comparsi dei pacchetti ICMP di questo tipo:
altrimenti ci sono solo solo echo request/reply (type 8 e type 0) da/verso il router. Riattivando IPv6 invece ci sono molti pacchetti ICMPv6 di tipo Neighbor Solicitation e Neighbor Advertisement.
Mi sa che Sky Wifi filtra qualcosa di troppo o è proprio un limite del MAP-T?
Comunque disattivando IPv6 il risultato non cambia, funziona solo con gli ePDG .129 e .144 (oggi mi rifunziona anche il primo).
@dariuccio83 Beh ... port unreachable...direi che non risponde nessuno quando prova ad instaurare il tunnel. Sarebbe carino vedere il pcap completo però
nanomad come te lo mando?
dariuccio83 Telegram, il mio utente ha lo stesso nick del forum
dariuccio83 Comunque ho giocato un po' con gli endpoint VoWifi di W3 e MTU della mia rete.
Come prima cosa ti direi che gli endpoint epdg se ne sbattono altamente della MTU configurata sull'APN IMS, quindi forse quell'use network mtu non è la causa del problema ma lo "enfatizza" solamente.
Come seconda cosa sì non tutti gli endpoint si comportano allo stesso modo (forse non dipende nemmeno dall'IP il comportamento), alcuni non inviano mai pacchetti ESP più grandi di 1200-1218 byte, altri ti sparano 1476 byte.
dariuccio83 trabattaro Un riavvio mi sembra il minimo in questi casi, altrimenti può ricordare l’IP dell’ultimo ePDG agganciato senza fare una nuova query DNS. Forse basta mettere modalità aereo ma nel dubbio…
Confermo che con Iliad fibra funziona solo in questo modo:
. Mettere il cell in modalità aereo, attivare il solo Wifi
. Riavvio
. Togliere modalità aereo.
Sto usando NextDNS perché non riesco ad inserire una entry DNS nella iliadbox + ePDG .129, non ho provato il .144.
Senza riavviare non c'è modo. Concordo nel dire che iOS si tenga in cache le query DNS fatte precedentemente e che per ripulire va riavviato
handymenny in serata faccio altre prove e vi mando il pcap…
trabattaro prova anche con il .144. Una volta andato a me il riavvio non serve più. Se continua a bloccarsi prova a dissociare e riassociare la rete Wi-Fi da Impostazioni
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
