Il problema dei chip ethernet con Big Sur

 Ad una parte dei possessori di computer della Mela con uscite USB-C o Thunderbolt 3 capita di volersi connettere ad una rete cablata: talvolta il wifi ha un livello troppo basso o manca del tutto. È d’obbligo quindi un adattatore ethernet connesso alle USB-C del Mac.

Purtroppo, con il passaggio a macos 11 Big Sur alcuni di questi adattatori hanno smesso di essere affidabili: appena connessi va tutto bene, possono funzionare per ore con un uso normale di internet; poi c’è la necessità di una video conference (nel periodo attuale, quasi sempre e magari più ore al giorno) e a metà della conference (o subito, o alla fine, o magari dopo tre collegamenti perfetti) tac... Meet avvisa che non sei collegato ad internet!

Se sei fortunato, stacchi il dispositivo ed il Mac gira sul wifi e dall’altra parte non se ne accorge nessuno; se però esiti per più tempo o non c’è wifi disponibile... il collegamento è andato. L’unica cosa da fare è staccare il dispositivo (che potrebbe anche essere un hub, con magari collegato un hard disk - con conseguenti lamentele da parte di macos “come ti permetti di togliermi un disco senza avvisarmi?” o con l’iPad, da dove stavi facendo vedere uno schizzo a mano libera - e allora lì se ne accorgono tutti). Riconnettendo il dispositivo la rete torna e probabilmente darai la colpa al router, allo switch, al provider internet ed altri. Nessun reset invece, se stacchi solo il cavo ethernet.

Poi ti capita la stessa cosa fuori casa e arriverai a pensare che le porte del Mac sono difettose o che il dispositivo non funzioni più. Io ho acquistato un altro hub per questo motivo, per poi trovarmi nella stessa situazione. Soliti test: collego il tutto alla porta dall’altra parte del Mac, provo a togliere l’ad-block, controllo sul log del dhcp, controllo nel log di sistema... nulla.

Allora ti butti a cercare sulla rete: Google, Bing, Duckduckgo. Il risultato alla fine è persino semplice: il driver di Apple (nuovo in Big Sur) attivato dal dispositivo ha un baco: quando il traffico comincia a farsi pesante (come in una video-call) può incappare in un overflow e andare in crash! E lì c’è poco da fare: per il dhcp non esisti più, perché dovrebbe spedirti segnali? Ed ecco anche spiegato perché staccando e riattaccando la rete torna: alla nuova connessione il driver viene ricaricato e tutto funziona, fino al prossimo crash.

La prima soluzione è che Apple corregga il problema: sperabile ma non probabile! Il baco esiste dalla prima versione di Big Sur a settembre 2020: se dopo sei mesi è ancora lì, non ci sono grandi speranze; inoltre l’adattatore di Apple funziona (dicono).

L’altra soluzione è di armarsi di santa pazienza... Prima cosa: scoprire il tipo di chip che gestisce l’ethernet su vostro dispositivo. Semplice: tenere premuto Option, menu Mela, Informazioni sul computer. Vi si apre una panoramica di tutto quello che c’è nel macbook; con il dispositivo collegato, selezionare USB dalla lista a sinistra; nella lista che compare a destra cercate USB 10/100/1000 e selezionatelo. Nel mio caso, Realtek, con ID 8153. Dalla ricerca in rete abbiamo visto che è proprio uno dei modelli incriminati...

Quando si parla di fortuna: ho acquistato due hub, entrambi con lo stesso chip... Va beh! Andiamo sul sito di Realtek e cerchiamo il driver adatto (in questo momento questo è il link): deve coincidere ovviamente il numero del chip ed il sistema operativo. In questo caso viene giù un dmg con un installer... Fermi! Niente doppio click! Il problema è che macos 11 ha un ulteriore strato di protezione, chiamato SIP (System Integrity Protection), che non lascia installare nulla silenziosamente nelle cartelle di sistema, anche se firmato dallo sviluppatore.

Da qui in poi, attenzione: non mi prendo responsabilità per quello che può accadere sul vostro computer: dobbiamo andare all’interno di macos!

Quindi, stacchiamo il dispositivo; ora occorre far ripartire il mac in Recovery Mode, dove abbiamo accesso di amministrazione a cose nascoste (e pericolose da modificare!). Quando ci siamo, apriamo il Terminale usando uno dei menu e dentro scriviamo

csrutil disable

seguito da invio. Abbiamo appena disabilitato le sicurezze! Dal menu Mela riavviamo il Mac e, una volta ripartito, finalmente installiamo il driver (se ce n’è più di uno, nel mio caso ho scelto quello che nel nome ha la parola ethernet). Durante l’installazione chiederà la password di amministratore e potrebbe anche chiedere di approvare l’estensione nelle preferenze di sistema (come anche Catalina ci aveva abituati). Ora proviamo ad attaccare il dispositivo ethernet, apriamo nuovamente le informazioni sul computer: vediamo che quello che compariva come un generico usb-ethernet ora ha il nome del produttore del chip (Realtek)! Significa che è stato caricato il nuovo driver, che infatti vediamo in figura in Nome Kext.

Bene! Ora dobbiamo rimettere a posto le sicurezze. Stacchiamo l’apparecchio e riavviamo nuovamente in Recovery Mode, apriamo il terminale e scriviamo, ovviamente

csrutil enable

Nuovo riavvio. Se connettendo il dispositivo, questo compare con il nome Realtek, siamo a posto! Se invece compare come scheda generica USB 10/100/1000, allora è stato nuovamente caricato il driver Apple e quello nuovo è stato bloccato dalle sicurezze.

Allora, sempre dalle Informazioni sul sistema, scegliamo la voce “Software disabilitati”: di sicuro ci troveremo il nostro driver, con una denominazione importante (riporto il mio caso):

ZYM2ETK3E7 com.realtek.driver.AppleRTL815XEthernet

Il primo codice è quello che ci interessa: è l'identificazione dello sviluppatore. Ora ritorniamo in Recovery Mode, apriamo il terminale e controlliamo che non esista ancora un record per questo sviluppatore (il comando fa una lista dei codici ammessi):

spctl kext-consent list

Solo se la risposta è vuota oppure non contiene "ZYM2ETK3E7", possiamo aggiungere l’eccezione:

spctl kext-consent add ZYM2ETK3E7

Naturalmente, se stiamo lavorando per un'altra estensione di altro produttore, dovremo inserire il codice di quel produttore.

Non stiamo aprendo il nostro Mac a malintenzionati, stiamo solo dicendogli che quello sviluppatore è noto: ci sarà sempre bisogno di autorizzare un eventuale software. Ora riavviamo, controlliamo per scrupolo che connettendo il dispositivo parta sempre il software Apple (compare come generico fra le schede di rete), quindi apriamo il Terminale e scriviamo

sudo kextload -b com.realtek.driver.AppleRTL815XEthernet

Il comando prova a caricare il nuovo driver e ci avvisa, tramite terminale (ma anche con un dialogo) che l’estensione è stata bloccata e bisogna autorizzarla dalle Preferenze di Sistema. Se infatti apriamo le Preferenze e andiamo nella sezione Sicurezza e Privacy, tab Generali, troveremo una scritta che chiede di autorizzare la nuova estensione. Dopo aver sbloccato la finestra con un click sul lucchetto e fornito la password, possiamo autorizzarla e quando collegheremo nuovamente il dispositivo, questa volta verrà caricato il nuovo driver e non quello generico: il problema è risolto! Posso affermarlo perché è una settimana che la rete cablata è connessa tutto il giorno, con grossi carichi (più video chiamate al giorno)!

C'è anche da notare che, nel caso di un MacbookPro, chiudendo il lid e mandando il computer in stop, l'interfaccia si spegne, permettendo al Mac di passare in modalità sleep! Cosa che con il driver di Apple non succedeva!