E' possibile recuperare i dati VOIP interrogando l'ACS?

[Yramrag]

Ciao a tutti,
sto provando a recuperare i dati voip dall'ACS tramite tr069, ma arrivo solo fino a un certo punto.

Premessa: ho già i dati voip recuperati dal modem, ma vorrei riuscire ad ottenerli in modo indipendente dal dispositivo per ogni evenienza.

Ho provato sia con honeything che con easycwmp; in entrambi i casi sono riuscito a installare ed eseguire le prove indicate nella documentazione... e qua mi fermo.

Mi sembra che easycwmp sia più completo, quindi mi sono concentrato più su questo strumento.
Seguendo la guida, su un terminale lancio
/usr/sbin/ubusd -s /var/run/ubus.sock
e su un altro
/usr/sbin/easycwmpd -f -b

Dopo l'avvio iniziale riesco a inviare i comandi tramite ubus; più in dettaglio

$ sudo ubus list -v
'tr069' @5f3e1da2
    "notify":{}
    "inform":{"event":"String"}
    "command":{"name":"String"}
$

Usando due terminali riesco a usare "notify" e "inform" con i vari "event", ma non ho idea di dove trovare i vari "command"; inoltre penso dovrei creare una envelope con i parametri voip... ma probabilmente il mio google-fu è molto arrugginito, perché non trovo un esempio pratico che sia uno

(tutte le prove fatte in macchina virtuale con Ubuntu 16.04.4)

Suggerimenti?

[Totix92]

Interessa anche a me, sarebbe utile anche capire come riuscire a tirare giù i firmware dei router del provider.

[Yramrag]

Dato che non ne vengo a capo ho deciso di fare un passo indietro.

Se invio "a mano" con python un messaggio all'ACS ottengo una risposta che mi sembra corretta, ad esempio:

1.py

import requests

url="http://acswind.wind.it:7003/cwmpWeb/CPEMgt"
headers = {'content-type': 'text/xml'}

body = """<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:cwmp="urn:dslforum-org:cwmp-1-0">
[...]/troppo altro testo da riportare qui
"""

response = requests.post(url,data=body,headers=headers)

print response.content

$ python 1.py 
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cwmp="urn:dslforum-org:cwmp-1-2">
<SOAP-ENV:Header>
<cwmp:ID SOAP-ENV:mustUnderstand="1">1</cwmp:ID>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<cwmp:InformResponse>
<MaxEnvelopes>1</MaxEnvelopes></cwmp:InformResponse></SOAP-ENV:Body>
</SOAP-ENV:Envelope>
$

Poi però dovrei inviare un messaggio vuoto, e ottenere una risposta dall'ACS... ma non ricevo mai nulla (print response.content mi ritorna una stringa vuota).

Sicuramente sbaglio qualcosa (immagino che il messaggio vuoto non sia "vuoto" come lo aspetta lui), ma cosa?

[Yramrag]

Confermo che sbaglio qualcosa.
Usando un'estensione di Chrome per inviare delle richieste http, dopo l'invio del messaggio vuoto ottengo una risposta che sembra valida.
È un metodo decisamente barbaro però

Se riesco stanotte ci guardo

[Yramrag]

Niente, ancora nulla

Sbaglio ancora qualcosa; riesco a fare:

1. CPE -> ACS: mando il messaggio di Inform
2. ACS -> CPE: ricevo la risposta InformResponse
3. CPE -> ACS: mando il messaggio VUOTO
4. ACS -> CPE: ricevo il messaggio di SetParameterValues
5. CPE -> ACS: mando il messaggio SetParameterValuesResponse
6. ACS -> CPE: VUOTO (???) mentre mi aspetterei di ricevere un messaggio GetParameterValues

[FrancYescO]

Originariamente inviato da Yramrag

Niente, ancora nulla

Sbaglio ancora qualcosa; riesco a fare:

1. CPE -> ACS: mando il messaggio di Inform
2. ACS -> CPE: ricevo la risposta InformResponse
3. CPE -> ACS: mando il messaggio VUOTO
4. ACS -> CPE: ricevo il messaggio di SetParameterValues
5. CPE -> ACS: mando il messaggio SetParameterValuesResponse
6. ACS -> CPE: VUOTO (???) mentre mi aspetterei di ricevere un messaggio GetParameterValues

non mi stupirei che abbiano modificato qualche cosa nel SetParameterValuesResponse e si aspettino di ricevere qualche parametro in più fuori standard

[Yramrag]

Originariamente inviato da FrancYescO

non mi stupirei che abbiano modificato qualche cosa nel SetParameterValuesResponse e si aspettino di ricevere qualche parametro in più fuori standard

Tutto è possibile, ma mi stupirei ancora meno se l'errore fosse dalla mia parte

[FrancYescO]

comunque io ho provato un pò con quello tiscali (ha dietro un server freeacs)... sembra rispondermi più o meno sempre correttamente ma mi fermo io perchè dopo l'auth inziale arrivano le richieste tipo GetRPCMethods o GetParameterValues a cui non so il router originale come avrebbe risposto (semplicemente perchè non gli ho sniffato il traffico)

infatti ho semplicemente provato a simularmi come un'altro modem con gli schemi trovati qui

https://github.com/jerrypnz/clj.tr06...ster/resources
o qui
https://github.com/dpavlin/perl-cwmp...ster/t/methods

e tenendo come base l'analisi fatta qui:
http://djuro82.blogspot.it/2011/05/t...visioning.html
e in secondo piano (troppo lunga ) la documentazione ufficiale:
https://cwmp-data-models.broadband-f...#TR-069%20RPCs

ancora non mi è chiarissimo a cosa serva l'indirizzo di ConnectionRequestURL che si da nella prima request di Inform

tu i body delle request da mandare dove li hai recuperati?

infine cito anche questo progetto di github che sembra il più semplice tra quelli analizzati (che erano un pò più invasivi installandosi a livello di sistema operativo) e che potrebbe aiutarci nell'evitare di fare tutte le request "a manina":
https://github.com/johnblackford/cwmpwalk

qui mi son fermato nella fase iniziale perchè è per py3 e io avevo pronto il due e dopo una giornata di prove e letture mi ero rotto

[Yramrag]

Originariamente inviato da FrancYescO

tu i body delle request da mandare dove li hai recuperati?

Anch'io ho usato questo: http://djuro82.blogspot.it/2011/05/t...visioning.html
Ho preso il primo esempio (Inform) e l'ho adattato ai miei dati.

I dati del DeviceId e del successivo ParameterList li ho recuperati dal file di configurazione del modem.

La lista dei parametri definita in ParameterList l'ho ridotta da [12] a [8] tenendo solo:

<Name>InternetGatewayDevice.DeviceSummary</Name>
<Name>InternetGatewayDevice.DeviceInfo.SpecVersion</Name>
<Name>InternetGatewayDevice.DeviceInfo.HardwareVersion</Name>
<Name>InternetGatewayDevice.DeviceInfo.SoftwareVersion</Name>
<Name>InternetGatewayDevice.DeviceInfo.ProvisioningCode</Name>
<Name>InternetGatewayDevice.ManagementServer.ConnectionRequestURL</Name>
<Name>InternetGatewayDevice.ManagementServer.ParameterKey</Name>
<Name>InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.1.ExternalIPAddress</Name>

Ho anche provato ad aumentarla a [16] aggiungendo questi altri parametri,

<Name>InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Name</Name>
<Name>InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.SIP.ProxyServer</Name>
<Name>InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.SIP.RegistrarServer</Name>
<Name>InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.SIP.UserAgentDomain</Name>
<Name>InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.1.Enable</Name>
<Name>InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.1.DirectoryNumber</Name>
<Name>InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.1.SIP.AuthUserName</Name>
<Name>InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.1.SIP.AuthPassword</Name>

ma il SetParameterValues che segue è sempre uguale.

Per rispondere all'altra domanda:

ancora non mi è chiarissimo a cosa serva l'indirizzo di ConnectionRequestURL che si da nella prima request di Inform

da quello che ho capito è un indirizzo che consente all'ACS di "stimolare" il CPE ad iniziare una sessione.
Nel mio caso è del tipo http://ip.esterno.del.modem_:_porta/stringa_random, con tanto di ConnectionRequestUsername e ConnectionRequestPassword (casuali ma uguali )

Lo Zyxel dovrebbe avere il port mirroring, mi sa che conviene provare a sniffare il traffico e vedere che messaggi passano

Edit: pare di sì, sperando che funzioni...

[FrancYescO]

il ConnectionRequestUsername almeno nel mio caso è così formato OUI-ProductClass-SerialNumber ma comunque insieme al ConnectionRequestPassword lo negoziano: in pratica il CPE comunica il ConnectionRequestURL dove interrogarlo poi l'ACS chiede al CPE di impostare quel username e password per fargli fare l'accesso (per far cosa poi su quell'indirizzo non si sà ) ... ma forse tutto ciò a noi serve a poco

inoltre in quell'analisi non viene data molta importanza al valore dell'header mustUnderstand che invece ho notato essere anchesso cruciale: se nelle request a seguire da parte del CPE non viene modificato con quello che da l'ACS in fase di inform, l'ACS non ti risponde

riguardo la ParameterList anche quelli aggiuntivi da dove li hai tirati fuori? io nelle config del router non ho proprio nulla a riguardo credo facciano parte del firmware e ancora non ho capito se sono stringhe standardizzate o meno (se non si fosse capito mi riferisco proprio al nome dei parametri, e non al valore come username e password del voip)

altra cosa importante credo sia che nel messaggio di inform dobbiamo simulare lo stato di reset completo del CPE e non di riavvio, perchè credo che sia solo in quel caso che l'ACS ci mandi la configurazione completa

comunque vorrei riuscire a fare almeno un py che faccia la parte di inform (salvandosi i JSESSIONID e l'header mustUnderstand) ridurrebbe già di molto i tempi per poi fare le request successive dato che ad ogni errore L'ACS tende a terminarti la sessione e quindi bisogna reiniziare da capo a ricopiare tutti i valori a manina

[Yramrag]

Originariamente inviato da FrancYescO

inoltre in quell'analisi non viene data molta importanza al valore dell'header mustUnderstand che invece ho notato essere anchesso cruciale: se nelle request a seguire da parte del CPE non viene modificato con quello che da l'ACS in fase di inform, l'ACS non ti risponde

A me non risponde anche se lo modifico, gli starò antipatico (vado a memoria però, non riesco a provare adesso).

riguardo la ParameterList anche quelli aggiuntivi da dove li hai tirati fuori? io nelle config del router non ho proprio nulla a riguardo credo facciano parte del firmware e ancora non ho capito se sono stringhe standardizzate o meno (se non si fosse capito mi riferisco proprio al nome dei parametri, e non al valore come username e password del voip)

Sempre dal file di configurazione (più precisamente dal file zcfg_config.json), andando un po' "a sentimento".

altra cosa importante credo sia che nel messaggio di inform dobbiamo simulare lo stato di reset completo del CPE e non di riavvio, perchè credo che sia solo in quel caso che l'ACS ci mandi la configurazione completa

Infatti, nell'inform l'evento "0 BOOTSTRAP" dovrebbe indicare "riavvio in seguito a factory reset", e invece "1 BOOT" dovrebbe essere "riavvio semplice" (da come l'ho capita).

Se riesco nei prossimi giorni provo a sniffare un po' di traffico; vediamo che salta fuori

[Yramrag]

Originariamente inviato da Yramrag

Se riesco nei prossimi giorni provo a sniffare un po' di traffico; vediamo che salta fuori

Piccolo aggiornamento: usando port mirroring + wireshark + connessione forzata cambiando l'intervallo di inform, riesco a catturare le comunicazioni tra modem e ACS; purtroppo non ho abbastanza tempo da dedicarci adesso (e non avevo mai usato wireshark fino a oggi pomeriggio )

[Yramrag]

Promemoria: devo provare a sniffare dopo un factory reset...

[Yramrag]

Sono riuscito a recuperare i dati voip con wireshark:

• scollegare il cavo telefonico dal modem;
• fare un factory reset;
• attivare il port mirroring (che probabilmente è stato disattivato dal reset);
• far partire wireshark;
• solo a questo punto ricollegare il cavo telefonico al modem;
• fermare wireshark quando il telefono risulta "Registered" dall'interfaccia del modem.

TUTTAVIA, temo non sia possibile recuperarli interrogando l'ACS.

Nel mio caso, almeno, i dati voip arrivano in seguito a un Inform con un evento di tipo 6 CONNECTION REQUEST, quindi è l'ACS stesso che "fa il primo passo" stimolando il CPE.
Se mando "a mano" un Inform di questo tipo, l'ACS mi risponde "204 No Content" perché non se lo aspetta.

Quindi temo di essere in un vicolo cieco

Edit: confermo che la password del voip è corretta; è la stessa che avevo già recuperato in precedenza.

[FrancYescO]

Non ho ben capito alcune cose..

-il port mirroring lo hai attivato sulla porta HTTP del CPE (quella che comunica in fase di inform nel ConnectionRequestURL)? quindi i dati arrivano li?
-la comunicazione vera e propria CWMP la riesci a sniffare con wireshark?

l'ACS fa quel passo in base a qualcosa che il CPE gli ha comunicato nelle comunicazioni precedenti, il tutto sta nel simulare quello.
insomma chiedere direttamente la password probabilmente non si può fare.
ma bisogna replicare un "hei mi sono resettato" ricevendo di conseguenza tutta la config con la password

il portmirroring è una bella trovata ma credo che lo Zyxel è l'unico modem tanto aperto fornito dagli ISP (infostrada) a permetterlo... capendo il meccanismo riusciremo invece facilmente a replicarlo per tutti gli ISP

PS. se mandi un salvataggio della comunicazione sniffata (magari depurata da dati sensibili) mi piacerebbe dare un occhio anche a me

[Yramrag]

Originariamente inviato da FrancYescO

Non ho ben capito alcune cose..

-il port mirroring lo hai attivato sulla porta HTTP del CPE (quella che comunica in fase di inform nel ConnectionRequestURL)? quindi i dati arrivano li?

Guarda qui:
https://www.hwupgrade.it/forum/showp...postcount=1212
ho abilitato il port mirroring su ptm0 IN/OUT verso la porta LAN a cui ero collegato: da quello che ho capito replica (mirroring) tutto il traffico anche sulla porta LAN selezionata.

-la comunicazione vera e propria CWMP la riesci a sniffare con wireshark?

Esatto, probabilmente solo grazie al port mirroring (non ho provato senza).

l'ACS fa quel passo in base a qualcosa che il CPE gli ha comunicato nelle comunicazioni precedenti, il tutto sta nel simulare quello.
insomma chiedere direttamente la password probabilmente non si può fare.
ma bisogna replicare un "hei mi sono resettato" ricevendo di conseguenza tutta la config con la password

E' possibile; ma vista l'ora non avevo le forze di provare oltre

il portmirroring è una bella trovata ma credo che lo Zyxel è l'unico modem tanto aperto fornito dagli ISP (infostrada) a permetterlo... capendo il meccanismo riusciremo invece facilmente a replicarlo per tutti gli ISP

Credo possano farlo anche il Fritz e il DLink (cercando tra settaggi più o meno nascosti).

PS. se mandi un salvataggio della comunicazione sniffata (magari depurata da dati sensibili) mi piacerebbe dare un occhio anche a me

Vedo cosa riesco a fare

[FrancYescO]

Stavo dando un occhio a quello che hai sniffato (grazie) e non so se lo hai notato ma sembra che durante la negoziazione cambi il server acs:

quello iniziale è acswind.wind.it:8016
mentre quello che poi ciccia fuori i parametri è acswind.wind.it:7003 ... la request con il 6 CONNECTION REQUEST l'hai mandata al server giusto?

intanto pian piano sto replicando la comunicazione con l'ACS tiscali, per ora sembra rispondere come mi aspetto, e sembra essere anche più semplice della comunicazione con quello infostrada... spero di arrivare quanto prima al punto

[Yramrag]

Originariamente inviato da FrancYescO

Stavo dando un occhio a quello che hai sniffato (grazie) e non so se lo hai notato ma sembra che durante la negoziazione cambi il server acs:

quello iniziale è acswind.wind.it:8016
mentre quello che poi ciccia fuori i parametri è acswind.wind.it:7003 ... la request con il 6 CONNECTION REQUEST l'hai mandata al server giusto?

Io ho sempre usato acswind.wind.it:7003, che è quello indicato nel file di configurazione del modem; in realtà il server è lo stesso, ma la porta è diversa.

Stasera ci guardo, perché nel file di configurazione del modem non è mai indicata la porta 8016, e non so da dove l'abbia tirata fuori...

[FrancYescO]

Originariamente inviato da Yramrag

Stasera ci guardo, perché nel file di configurazione del modem non è mai indicata la porta 8016, e non so da dove l'abbia tirata fuori...

forse è quello "sbagliato" che viene usato solo appena resettato, poi viene corretto alla prima comunicazione

comunque, correggimi se sbaglio ma all'url di connection request (quello su cui il cpe si mette in listening) in pratica viene fatta solo una richiesta http, risposta in un modo che sembra statico, e senza alcuno scambio di dati all'interno ... forse gli serve solo per capire se il CPE ha accettato i parametri di user e password mandati in fase di inform (che per tiscali son sempre uguali) per poi continuare la comunicazione nello stesso modo

[Yramrag]

Originariamente inviato da FrancYescO

forse è quello "sbagliato" che viene usato solo appena resettato, poi viene corretto alla prima comunicazione

Riguardano i dati di wireshark, ti confermo la connessione alla porta 8016 viene usata solo nel primo scambio di informazioni.

comunque, correggimi se sbaglio ma all'url di connection request (quello su cui il cpe si mette in listening) in pratica viene fatta solo una richiesta http, risposta in un modo che sembra statico, e senza alcuno scambio di dati all'interno ... forse gli serve solo per capire se il CPE ha accettato i parametri di user e password mandati in fase di inform (che per tiscali son sempre uguali) per poi continuare la comunicazione nello stesso modo

Sì, dovrebbe essere così.
Da come l'ho capita:

• convenevoli e amenità;
• ACS -> CPE: GET ip: porta/stringa, con ConnectionRequestUsername e ConnectionRequestPassword che l'ACS stesso ha inviato al CPE in precedenza;
• autorizzazione accettata;
• CPE -> ACS: evento di tipo 6 CONNECTION REQUEST, entro 30 secondi;
• ACS -> CPE: trasmissione dati voip.

Per "uguali" intendi che sono costanti, o uguali tra loro?
Nel mio caso corrispondono ai dati di "Connection Request User Name" e "Connection Request Password" che sono uguali (ovvero username = password), ma probabilmente sono rigenerati/re-inviati al reset.