Messaggi Spostati

edofullo Se riuscissi a fare andare sta dannata chiavetta in modalità seriale invece di cdc_ether proverei anche il firewall.

Se e' una chiavetta Huawei, va riflashata con firmware Stick (versione 21.x) invece che HiLink (22.x). Il resto del codice versione va di pari passo, 21 vs 22 e' come se fosse un "flag" per indicare il tipo (anche la prima cifra... 1x Qualcomm, 2x HiSilicon)

      LATIITAY È una ZTE, MF79U che sembra simile alla MF825 però purtroppo quel comando nonostante dia come risultato OK non la fa switchare in modalità seriale.

      Nessuna ttyUSB viene rilevata.

      In caso apro un topic però

          edofullo hai provato anche USB_MODE_SWITCH in usb_mode 0, oltre MODE_SWITCH in FACTORY? Cmq curioso che funzioni la radio anche in download mode, sulle Huawei se ricordo bene resta in modalita' offline (o cmq la radio non e' usabile)... Cmq non so se la MF79U supporta anche il vecchio download mode via seriale, oppure solo il nuovo debug mode "nativo" dei SoC ZTE...

              LATIITAY hai provato anche USB_MODE_SWITCH in usb_mode 0

              result: failure, però ho visto che qualche russo su qualche forum c'è riuscito, provo ad indagare.

                  LATIITAY

                  edofullo forum c'è riuscito, provo ad indagare

                  just fyi perchè qui siamo OT.

                  Sul forum russo 4pda.to ci sono degli eseguibli che mettono la chiavetta in recovery dove prende comandi AT.
                  Poi con un comando AT si può mettere in AT + RDNIS + MODEM e sembrava funzionare... tempo di staccarla dalla virtual machine e dal PC e collegarla ad OpenWRT ed è tornata in modalità cdc_ether.

                  Peraltro AT è un delirio perchè è come se prendesse un carattere alla volta il terminale quindi l'unico modo che ho trovato è usare echo "AT+COMANDO" | cu -l /dev/ttyUSB1 per ogni comando.

                  Mi sa che lascio perdere, per ora.

                        edofullo se il comando AT era ZCDRUN e' strano che non sia persistente... Oppure, forse potresti provare anche con lui (tipo AT+ZCDRUN=E) alla fine dopo i comandi di prima che ti avevano dato insieme la radio funzionante e le TTY... 🤔

                        (/OT ma se scopri qualcosa a 'sto punto scorporiamo in un altro thread 😇)

                            LATIITAY Il comando è AT+ZMODE=N

                            Con i seguenti valori:

                            con N:

                            0: normale, cdc_ether + CDROM (19d2:1405)
                            1: cdc_ether + AT + Modem (forse) + ADB (19d2:0536)
                            2: Debug/Download, AT (19d2:1602)

                            Per passarlo da 1405 a 1602 per windows c'è un binario sketchy da far partire, ora ho visto che qualcuno ha postato anche uno script per linux (che ho copiato qui), in pratica c'è da mandare un comando SCSI al cdrom (che non è il classico eject), solo che non c'è il pacchetto per openwrt che sto provando a compilare a mano.

                            Comunque ora ho fatto su windows, staccato, messo su openwrt ed ha tenuto la modalità 2... ieri sera invece mi si è resettato.

                            FONTE 4PDA (RUSSO)

                                edofullo comando SCSI se serve dovresti poterlo mandare in automatico modificando il "db" di usb_modeswitch (oppure il "ridotto" usbmode di OpenWrt)... Occhio che quindi mi sa che nel caso ti tocca compilare pure i kmod per SCSI e CD dentro OpenWrt...

                                Nella modalita' 2 quindi funziona anche il modem? O serve la modalita' 1? Che mi sembra la migliore forse, cosi' hai entrambi, e magari e' come sulle Huawei con fw 21.x dove la pseudo-Ethernet e' "diretta" senza NAT e controllabile con un diverso comando AT (^NDISDUP per Huawei, sicuramente diverso per ZTE)... L'unico modo per avere performance piene in 4G+ e' questo, con l'emulazione di ppp via seriale oltre una certa velocita' non va...

                                    LATIITAY Occhio che quindi mi sa che nel caso ti tocca compilare pure i kmod per SCSI e CD dentro OpenWrt...

                                    Mmmhhh... perchè?

                                    edit: è vero, spero sia la stessa versione del kernel

                                    LATIITAY Nella modalita' 2 quindi funziona anche il modem? O serve la modalita' 1?

                                    Serve per forza la uno, che dovrebbe avere tutto attivo.

                                    LATIITAY e magari e' come sulle Huawei con fw 21.x dove la pseudo-Ethernet e' "diretta" senza NAT

                                    La pseudo ethernet che crea usando cdc_ether è la sua maledettissima rete locale nattata (192.168.0.0/24) purtroppo.

                                    Metto un dmesg per farti capire meglio (modalità 1):

                                    [    6.920280] usbcore: registered new interface driver usbserial_generic
[    6.921492] usbserial: USB Serial support registered for generic
[    6.930034] cdc_ether 2-1:1.0 eth1: register 'cdc_ether' at usb-0000:02:1b.0-1, ZTE CDC Ethernet Device, 34:4b:50:00:00:00
[    6.931525] usbcore: registered new interface driver cdc_ether
[    6.935280] usbcore: registered new interface driver cdc_ncm
[    6.945547] PPP generic driver version 2.4.2
[    6.947809] NET: Registered protocol family 24
[    6.952146] usbcore: registered new interface driver qmi_wwan
[    6.954551] usbcore: registered new interface driver rndis_host
[    6.957398] usbcore: registered new interface driver cdc_mbim
[    6.960569] usbcore: registered new interface driver option
[    6.961659] usbserial: USB Serial support registered for GSM modem (1-port)
[    6.965266] kmodloader: done loading kernel modules from /etc/modules.d/*
[    8.787073] 8021q: adding VLAN 0 to HW filter on device eth0
[    8.789548] br-lan: port 1(eth0) entered blocking state
[    8.790576] br-lan: port 1(eth0) entered disabled state
[    8.791732] device eth0 entered promiscuous mode
[    8.796581] br-lan: port 1(eth0) entered blocking state
[    8.797629] br-lan: port 1(eth0) entered forwarding state
[    8.803899] br-lan: port 2(eth1) entered blocking state
[    8.804948] br-lan: port 2(eth1) entered disabled state
[    8.806031] device eth1 entered promiscuous mode
[    8.806966] br-lan: port 2(eth1) entered blocking state
[    8.807907] br-lan: port 2(eth1) entered forwarding state
[    9.861916] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready

                                    Le ttyUSB[012] vengono registrate solo dopo che viene forzato con echo "19d2 0536" > /sys/bus/usb-serial/drivers/option1/new_id

                                    [  475.885076] option 2-1:1.2: GSM modem (1-port) converter detected
[  475.886157] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB0
[  475.887283] option 2-1:1.3: GSM modem (1-port) converter detected
[  475.888438] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB1
[  475.889545] option 2-1:1.4: GSM modem (1-port) converter detected
[  475.890563] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB2
[  475.891624] option 2-1:1.5: GSM modem (1-port) converter detected
[  475.892731] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB3

                                    La cosa che mi lascia perplesso è che sembra venire riconosciuto anche qmi_wwan e rndis, ma in realtà non sembrano funzionare, non vorrei vadano attivati via AT però vai a capire che comando usare... i russi pensano solo a cambiare IMEI e TTL 🤣

                                    QMI e RDNIS mi sembra di aver letto dovrebbero dare accesso direttamente al modem, però non penso proprio possa funzionare contemporaneamente alla modalità NAT, quindi ci sarà da fare qualcosa...
                                    Provo a taggare anche @handymenny che mi diceva che forse aveva fatto qualche test su telefoni con RDNIS

                                            edofullo edit: è vero, spero sia la stessa versione del kernel

                                            Ma non stai compilando tutto? O stai usando l'SDK di OpenWrt? Se usi l'SDK della stessa versione dovrebbe andar bene...

                                            Cmq questo serve solo se il cambiamento alla chiavetta non e' persistente e quindi devi inviare il comando alla periferica SCSI emulata anche da OpenWrt. Se non serve evita, tanta complicanza per nulla 😅

                                            edofullo Le ttyUSB[012] vengono registrate solo dopo che viene forzato con echo "19d2 0536" > /sys/bus/usb-serial/drivers/option1/new_id

                                            Si', questo e' normale se il driver option non ce l'ha, e' una whitelist hardcodata... /etc/rc.local is your friend 😇 (o se preferisci, puoi sempre fare uno script di "hotplug", ossia il rimpiazzo di udev made in OpenWrt... in questo caso dai un'occhiata a /etc/hotplug.json che ti dice come vengono chiamati gli script e per cosa)

                                            edofullo cdc_ncm [...] QMI e R[ND]IS

                                            In teoria e' uno di questi che bisognerebbe usare, pero' quel dmesg sta dicendo che ha caricato i driver... non che ha trovato le relative interfacce esposte dalla chiavetta...

                                            Prova a fare lsusb -t e vediamo cosa espone...

                                            edofullo non vorrei vadano attivati via AT però vai a capire che comando usare

                                            QMI pero' temo proprio di no, non credo ZTE abbia emulato il protocollo binario di Qualcomm pure nei suoi SoC... Pero' NCM o RNDIS forse... Con le Huawei col 21.x infatti si usa NCM ("moddato", il driver si chiama huawei_ncm perche' deve fare cose "speciali" per funzionare... dettagli dettagli 🤣)

                                            edofullo i russi pensano solo a cambiare IMEI e TTL 🤣

                                            Eh 😂 Cmq e' strano, per le Huawei quel forum e' letteralmente una miniera d'oro e di diamanti, possibile che per le ZTE nuove non si riesca a trovare nulla di "definitivo" per cambiare modalita'... .-.

                                                      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