[MisterFTTH]

OT: io ho paura vera delle capacità di @LuKePicci 

[larsen64it]

Visto che ci sono milioni di miliardi di queste chiavette, controllato l'ID in /etc/usb-mode.json del pacchetto usb-modeswitch?

[LuKePicci]

Si, l'ho controllato, c'è (anche se in quel file i valori target [t_vendor, t_product] sono specificati in decimale), ed è configurato per fare modeswitch della mia chiavetta dalla modalità di default :1446 a una qualsiasi tra quelle indicate in decimale, che includono sia :1436 (cdc_ether, cioè modem vecchio stile) e :140c (QMI, se ho ben capito). Però ci sono alcune cose strane.

Codice: [Seleziona]

               "12d1:1446": {
                        "*": {
                                "t_vendor": 4817,
                                "t_product": [ 4097, 5124, 5126, 5131, 5132, 5138, 5143, 5147, 5161, 5170, 5171, 5174, 5292, 5382, 5388, 5393 ],
                                "mode": "HuaweiNew",
                                "msg": [  ]
                        }
                },
msg è una lista vuota, mentre dovrebbe contenere l'id del messaggio di switch come definito all'inizio del file.
All'inizio del file non c'è il messaggio utile a fare switch in modalità QMI, c'è quello per lo switch in cdc_ether e nemmeno quello per lo switch in cdc_ether.

Qui c'è spiegato bene il problema per il caso specifico della mia chiavetta (e ti tutte quelle simili):
http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=1170

Su una macchina ubuntu sono riuscito a fargli fare manualmente lo switch in QMI, ma editando quel file json sul tch mi ha comunque fatto lo switch in cdc_ether, quindi dovrei capire meglio quale componente definisce il modeswitch. Leggendo i sorgenti di mobiled e dintorni (lua per lo più) ho capito che comunque dovrebbe essere possibilee definire dei modeswitch personalizzati tramite uci, non ho approfondito, ma in generale tutto il pacchetto mobiled sembra fare come dicevo affidamento su cdc_ether. Quindi benché usarla in QMI, una volta switchata, sia decisamente più semplice e "figo" (c'è anche il supporto in luci),  secondo me conviene capire perchè mobiled non va mai per fare la connessione dialup via cdc_ether, o al limite fargliela fare manualmente via chatscript (dai sorgenti si vede chiaramente che i comandi AT sono i soliti ben noti). Per la cronaca, anche la vm di ubuntu 12 su cui ho fatto le prove la setta in cdc_ether e ovviamente da lì funziona senza battere ciglio.

[mancene]

Un saluto,
vorrei utilizzare il TG789vac V2 con  ultimo firmware UNO sbloccato come router Access Point + ATA VoiP da collegare in cascata al un DGA4130
Per AGTOT so che c'è questa guida https://www.ilpuntotecnico.com/convertire-il-modem-agtot-in-router-access-point/
E' possibile ottenere lo stesso risultato solamente configurandolo correttamente tramite interfaccia?
Vorrei crearmi una sottorete e configurare un numero Voip Olimontel

Grazie

[larsen64it]

@LuKePicci
Prova ha date un occhiata al pacchetto wwan presente nelle sorgenti vant-f, noterai anche la presenza del pacchetto usbmode che non risulta installato.

[LuKePicci]

usbmode non risulta installato ma c'è. Alla fine ho capito perchè le modifiche al file usb-mode.json non me le prendeva, avevo fatto un errore. Sono riuscito a fargli fare modeswitch su :140c ma il driver QMI non si è preso carico del device.

Ho indagato un po' oltre, e in pratica ho scoperto che in linux in generale questo device (e i suoi simili https://www.freedesktop.org/wiki/Software/ModemManager/SupportedDevices/) è supportato per volere/proposta di huawei solo in modalità :1436 modem+cdc_ether per funzionare nell'una o nell'altra a seconda del modello preciso (la mia è una di quelle con firmware 11.x.x.x.x con la dicitura "Runs with PPP").
In ubuntu infatti, il device viene switchato in :1436 ma viene configurato mediante PPP sfruttando la modalità modem classica, e non via dhcp su cdc_ether (ignorando quindi il fatto che quest'ultima possibilità esista). A quanto ho letto, ci sono dispositivi Huawei più recenti della serie HiLink che invece questa modalità dhcp via cdc_ether la supportano davvero, e per questo motivo huawei pare abbia chiesto ai dev di usb_modeswitch di implementare lo switch a :1436 per tutte, così che le più vecchie avessero comunque la modalità modem disponibile, mentre le HiLink potessero funzionare in cdc_ether. Per questa ragione, e sempre per volere di huawei, in linux, per questi device, la modalità :140c modem+QMI non è proprio gestita perchè non è previsto che questi device vengano usati in linux in questa modalità. Invece in windows il driver huawei ufficiale switcha sempre in :140c così che su vista/7 e successivi funzioni in QMI, mentre su XP vada in modalità modem.

Veniamo al technicolor. Da quello che ho capito, mobiled supporta sia PPP (su modem seriale classico) che dhcp (su cdc_ether). ma a differenza di ubuntu prova a tutti i costi a far funzionare la mia chiavetta in dhcp via cdc_ether, ma qualcosa va storto durante il setup della connessione. Toccando qualcosa qui e lì nei sorgenti di mobiled ad un certo punto sono anche riuscito a fargli acquisire un ip ed impostare la route ma ha comunque deciso che la connessione era andata a finire male quindi me l'ha chiusa tramite interfaccia seriale di controllo (una delle interfacce seriali viene usata per impostare apn ed altro). Credo che mobiled sia semplicemente buggato o testato per funzionare solo sulle chiavette con firmware più nuovo per cui è effettivamente previsto che la cdc_ether funzioni. Tentare di farla andare in QMI è fuori questione, nemmeno in ubuntu. Ma se avete una chiavetta che funziona in QMI su ubuntu o un openwrt pulito probabilmente potreste riuscire a farla funzionare anche sul technicolor (non tramite mobiled però, che di QMI sembra non saperne nulla). L'analogo di 'mobiled' su openwrt pulito per connessioni PPP via modem cellulare si chiama '3g'. Non ho ancora capito cosa resti di questo protocollo nel firmware technicolor, ma mi pare evidente che a questo punto le strade sono quattro:
- ci rinuncio
- recupero le funzionalità stock di openwrt usando '3g' e la uso in PPP via modem
- costringo mobiled ad ignorare la modalità dhcp via cdc_ether sperando che me la faccia funzionare lui in PPP (ci credo poco)
- cerco di capire se il setup in modalità cdc_ether ha o meno delle chance concrete di funzionare e nel caso torno a vedere perchè mobiled fa casini (ci credo ancora meno, ma almeno potrei lavorarci su pc in comodità)

[larsen64it]

In openwrt usa proto-3g per gestirlo con luci, ti avevo detto di dare un occhiata al pacchetto wwan che è un mischione tra usb-modeswitch per la gestione degli id e proto-3g, vedrai che in /lib/network/wwan/ l'ID 12d1:1446 non esiste e per questo non viene gestita in automatico, magari creando il file copiandolo da un altro...

[LuKePicci]

wwan lo avevo già guardato, e appunto come hai detto è un mischione tra 3g, usbmode e altra roba. :1446 non viene gestito perchè :1446 non è una mode valida per wwan, deve appunto essere prima switchata in qualcos altro, e in usb-mode.json infatti è presente.

Comunque ho fatto un progresso, sono riuscito a connettermi da ubuntu in cdc_ether su :1436, rispetto al solito ppp su modem è un grosso passo avanti, ora so cosa starebbe cercando di fare mobiled, ho un buon presentimento.

edit: ok, gliel'ho fatta sotto il naso (letteralmente) https://imgur.com/a/008dQw5
ora sto scrivendo connesso dalla chiavetta sul tch, ma come si intravede dallo screen mobiled non è proprio convintissimo di essere connesso

ora volendo essere schizzinosi si potrebbe fare debugging su mobiled per capire come mai non risulta connesso ma in realtà così com'è adesso non è male

[larsen64it]

Io una prova a crearmi un file  12d1:1446 in /lib/network/wwan/ procedendo ad inserire le opzioni a tentativi la farei. Comunque già un bel passo in avanti.

[LuKePicci]

Ma in :1446 la chiavetta espone solo l'unità cd con i driver per windows e il lettore di schede sd. Cioè :1446 non è una chiavetta finchè non fai il modeswitch. In :1446 non c'è ne il modem ne la cdc_ether. Se in usb-mode.json tolgo la sezione che switcha :1446 in qualcosa di utile, da lsusb mi rimane appunto solo :1446 e mobiled non parte nemmeno. Ho provato anche a switchare su :140c (la QMI) e ad aggiungerlo come id compatibile al driver qmi_wwan che da quanto leggo in questo modo dovrebbe gestirla correttamente ma non sembra farlo, forse sbaglio qualcosa io ma su questo tentativo non andrei oltre visto che mobiled e la webui poi non funzionerebbero. Al punto di adesso invece nella webui funziona tutto, la gestione dei profili e degli apn, la visualizzazione delle stat e i vari toggle per abilitarla tranne che la da per disconnessa.

Le uniche cose che ci sono da fare per riprodurre questo risultato sono:

- aggiungere use_l3_ifname=1 come vedete qui sotto in /lib/netifd/mobiled.script

Codice: [Seleziona]

create_dhcp_interfaces() {
        local action="$1"

        json_select "dhcp"
        local ifname use_l3_ifname
        json_get_vars ifname use_l3_ifname

logger -t mobiled "debugging create_dhcp_if action=$1 interface=$interface ifname=$ifname use_l3_ifname=$use_l3_ifname"

        if [ -z "$ifname" ]; then
                proto_notify_error "$interface" "NO_IFNAME"
                return 1
        fi

        dhcp_ifname="@$interface"

+ #force l3 interface name
+ use_l3_ifname=1

        if [ "$use_l3_ifname" = "1" ]; then
logger -t mobiled "bringing up l3 ifname: $ifname"
                ifconfig "$ifname" up
                dhcp_ifname="$ifname"
        fi
- impostare il mac address dell'interfaccia cdc_ether, nel mio caso wwan0,  su 00:01:02:03:04:05 a causa di un bug noto ma mai risolto nel driver linux per cdc_ether

Se non fate la prima di queste due cose, mobiled non arriva mai a prendere l'ip e soprattutto non rimane agganciato all'apn ma continua a resettarlo. Non ho voglia di perderci altro tempo, ma sono convinto che se volete arrivare a far risultare il mobile come connesso dovete capite come mai e con che logica mobiled.script si ritrova normalmente con quel flag a 0, e perchè quando è a 0 quello script non funziona correttamente. Se non fate la seconda, dopo aver preso l'ip, l'interfaccia è semplicemente muta perchè i pacchetti che arrivano hanno tutti quel mac address come destinazione, diverso da quello dell'interfaccia cdc_ether, e quindi scartati.

edit: Nonostante io sia piuttosto sicuro che in :140c su windows questa maledetta funzioni via QMI, ho trovato un tale -piuttosto sgamato in materia- che nel tentativo di comprendere cosa avessero in mente quelli di huawei mentre progettavano il firmware di queste chiavette ha suggerito ad un altro utente di provare a "montare" il device cdc_ether sotto :1436 col driver cdc_wdm (quello da cui dipende QMI). Per farla breve l'ho provato anch'io e sembra funzionare, cioè ho il device wdm su cui posso fare query via uqmi tipo "uqmi -d /dev/cdc-wdm0 --get-imei". Non ho provato a far partire la connessione perchè ho dovuto restituire la sim funzionante che avevo preso in prestito per le prove oggi pomeriggio.
Per riuscirci ho fatto così: partendo da questa situazione

Codice: [Seleziona]

[ 1838.665000] usb 1-2: new high-speed USB device number 8 using ehci_hcd
[ 1838.797000] scsi24 : usb-storage 1-2:1.0
[ 1838.816000] scsi25 : usb-storage 1-2:1.1
[ 1839.392000] usb 1-2: USB disconnect, device number 8
[ 1843.521000] usb 1-2: new high-speed USB device number 9 using ehci_hcd
[ 1843.654000] option 1-2:1.0: GSM modem (1-port) converter detected
[ 1843.671000] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB0
[ 1843.717000] cdc_ether 1-2:1.1: wwan0: register 'cdc_ether' at usb-0000:00:0a.0-2, Mobile Broadband Network Device, 02:50:f3:00:00:00
[ 1843.752000] option 1-2:1.3: GSM modem (1-port) converter detected
[ 1843.772000] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB1
[ 1843.792000] option 1-2:1.4: GSM modem (1-port) converter detected
[ 1843.817000] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB3
[ 1843.835000] scsi30 : usb-storage 1-2:1.5
[ 1843.873000] scsi31 : usb-storage 1-2:1.6
[ 1844.855000] scsi 30:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
[ 1844.899000] scsi 31:0:0:0: Direct-Access     HUAWEI   SD Storage       2.31 PQ: 0 ANSI: 2
[ 1844.946000] sd 31:0:0:0: [sda] Attached SCSI removable diskho prima fatto l'unbind della cdc_ether:

Codice: [Seleziona]

echo "1-2:1.1" >/sys/bus/usb/drivers/cdc_ether/unbindpoi registrato l'id del device :1436 sul driver cdc_wdm:

Codice: [Seleziona]

echo "12d1:1436" >/sys/bus/usb/drivers/cdc_wdm/new_idil risultato in dmesg degli ultimi due passi è questo:

Codice: [Seleziona]

[ 1930.553000] cdc_ether 1-2:1.1: wwan0: unregister 'cdc_ether' usb-0000:00:0a.0-2, Mobile Broadband Network Device
[ 1986.341000] cdc_wdm 1-2:1.1: Ignoring extra header, type 15, length 13
[ 1986.347000] cdc_wdm 1-2:1.1: Ignoring extra header, type 6, length 5
[ 1986.355000] cdc_wdm 1-2:1.1: cdc-wdm0: USB WDM device
[ 1986.360000] cdc_wdm: probe of 1-2:1.2 failed with error -22
Se siete curiosi di vedere come la comunità open di linux e dintorni, molti anni fa, ha notato, capito e valutato le possibili strade per risolvere il problema del mac errato in cdc_ether, inclusa la possibilità di usare stabilmente QMI al suo posto, senza però intraprendere alcuna azione a riguardo andate qui: http://gnome-networkmanager.2324886.n4.nabble.com/MM-Huawei-E1820-and-NDISDUP-td13670.html

[larsen64it]

Understood
Il problema di queste chiavette che sono multifunzione e se non ben gestite non vanno e per farle andare bisogna forzare come hai fatto tu.
lsusb -v -d 12d1:1446 ti restituisce       bInterfaceClass         8 Mass Storage
lsusb -v -d 12d1:1436 ti restituisce       bInterfaceClass     255 Modem
e cosi via.

Huawei E173 12d1:1446 alias 12d1:1436 alias 12d1:140c

https://gist.github.com/rehno-lindeque/4500517
Roba da matti
E' un problema annoso in cui i produttori prendono hardware vecchio cambiano il fw e lo spacciano per nuovo. Sotto win non te ne accorgi con il cd auto installante  che ti mostra l'icona del nuovo dispositivo. Sotto linux dove i driver mancano bisogna indagare e a volte gli altarini si scoprono. Lo facevano ai miei tempi anche con le schede video: cambiavano il colore del pcb la forma del dissipatore oc via fw e le rivendevano al doppio del prezzo. Lasciamo perdere i processori poi.

Lista delle internet key compatibili (in teoria)
https://www3.zippyshare.com/v/huaoRVaP/file.html

@FrancYescO
Ti segnalo un problema con la dev 8.10.73
La funzione WiFi NSC nelle impostazioni eco è del tutto ininfluente se in on o off.
In pratica i led sono sempre disabilitati e si attivano se si instaura una connessione (la rete guest non viene proprio gestita).
E' un problema che mi porto dalla versione predente in cui al riavvio mi aveva addirittura disabilitati il wifi di default.
 

[FrancYescO]

@larsen64it sarebbe stato troppo bello se la nuova stable fosse stata senza bug...

[larsen64it]

Non è questione di bellezza ma di ottimismo.

[rusudanion]

Buongiorno dovrei usare uno di questi modem con qualsiasi firmware come modem di backup su chiavetta 3g.il problema è che non so come Inserire i dati per la connessione Wind. Qualcunoi può dire i passaggi? Grazie

[LuKePicci]

Inizia a dirci di più sul tuo modem, ce l'hai già o intendi acquistarne uno? Se ce l'hai, che firmware ha attualmente? Lo hai sbloccato? Che chiavetta 3g vuoi usare? Insomma facciamo in modo che la risposta alla tua domanda non debba per forza essere un poema epico omnicomprensivo su tutto lo scibile a riguardo. 
Comunque, arrivare ad inserire i dati è la parte facile, il difficile viene dopo.