RobertoMattioli beh anche un mio portatile del 2005 ha la Gigabit integrata... Il problema sono piu' che altro i portatili di fascia medio-bassa, che ancora oggi escono o con scheda Fast Ethernet, o proprio senza scheda cablata (solo Wi-Fi)... :/
Fabio Bizzi in realta' il meccanismo esiste anche in IPv4 ed e' simile a quello usato in IPv6, ossia vengono usati i messaggi di errore ICMPv4 Fragmentation Needed... La differenza con ICMPv6 Packet Too Big e' sostanzialmente che i router intermedi in IPv4 possono riframmentare a piacimento il pacchetto (sempre se non e' attivo il flag DF = Don't Fragment), mentre in IPv6 non possono, il messaggio di errore diventa end-to-end e quindi ci deve pensare la sorgente a modificare la dimensione dei pacchetti e ritrasmettere. Questo serve anche per evitare problemi di performance "invisibili" ai due endpoint se le MTU ridotte sono presenti solo in collegamenti tra router intermedi...
Inkubo e' un bug del router perche' avrebbe dovuto in automatico impostare 1452 di TCP MSS (che e' corretto) per una PPPoE con 1492 byte di MTU negoziata... Non solo, ma i BRAS di PF durante l'instauramento della PPPoE inviano anche un pacchetto di LCP Echo grande quanto l'MTU appena negoziata; se il pacchetto non viene tornato correttamente la MTU viene (o meglio dovrebbe essere) rinegoziata e abbassata in automatico... Quindi in teoria con PF, lasciando il clamping su auto, usando router "non buggati" dovrebbe regolarsi tutto in automatico anche su linee che hanno problemi di MTU a monte per colpa dei fornitori... (Fintanto che i problemi di MTU non sono transitori per via di rerouting temporanei al volo, ecco... Se c'e' un rerouting ma non cade la PPPoE, non viene mai ritestata e rinegoziata la MTU e quindi possono nascere i problemi 😅)
Fabio Bizzi su alcune connessioni PF usa 1480 invece che 1492 come MTU, quindi puo' darsi sia per questo che nel tuo caso hai dovuto impostare 1440 invece che 1452...