[nick.dd]

Salve a tutti! forse sono un po OT.. ma oggi ho preso il TG789vac v2 e l ho flashato con l'ultimo firmware iiNET, poi ho lanciato unlocker e con sommo stupore la procedura è andata a buon fine! c'è qualche bug.. ma va!

[miki8989]

potresti fare un ping -n 1000 192.168.1.1 e vedere questi lag spike se sono effettivamente rivolti al modem o ad altro ?

Purtroppo non sono a casa..
Appena torno faccio la prova

Credo però che sia un problema di modem perché il problema avviene di notte mentre di giorno è tutto ok (mio figlio mi dice che ieri notte con dslreport il down era a 140k.. Dopo 10  minuti e tornato a 17 mb)
Io non  orribile, come peraltro già detto, qos va a spasso...

Grazie

[Ansuel]

Salve a tutti! forse sono un po OT.. ma oggi ho preso il TG789vac v2 e l ho flashato con l'ultimo firmware iiNET, poi ho lanciato unlocker e con sommo stupore la procedura è andata a buon fine! c'è qualche bug.. ma va!

SI Certo funziona per qualsiasi modem technicolor 16.3
Io i test per esempio li ho fatti sull'iinet

[barese]

la procedura è reversibile? come faccio per ripristinare il modem come mamma tim me l'ha mandato? basta il reset alle imp d fabbrica?

[Ansuel]

Si dovrebbe

[^NiCo^]

effettivamente il bootp è l'unico modo (salvo bug per cui un reset o un aggiornamento non lasciano il root) per riportarlo alle impostazioni di fabbrica... forse nel tool inserirò un bottone hard reset. Che ne pensi ?

Se non ti porta via tanto tempo 

[Patatrak]

Se volessi usare il DGA4130 SOLO come modem e gestire TUTTO IL RESTO col mio fritzbox 7490 messo in cascata, sul DGA devo disabilitare tutto tranne la connessione PPP ?

[^NiCo^]

Abbiamo offuscato il programma (e te lo dice uno che vuole fare programmi open source) per il semplice motivo di non voler diffondere la falla a mezzo mondo. Già di per sé questa falla è molto critica (risolta nella 1.0.4), immagina se cadesse nelle mani sbagliate (molti modem hanno l'accesso admin/admin, quindi immagina i guai che uno potrebbe fare se dovesse avere l'accesso root....)

Siccome sono curioso ho continuato a cercare

Non è propio sconosciuta questa falla a quanto sembra, ne parlano anche sul forum di openwrt da luglio, se domani mi arriva il modem provo a sbloccarlo manualmente.
Dopo esser entrati come root tramite buco cosa fate ?
modificate /www/lua/cards_limiter.lua per mostrare il menù completo ?
/etc/config/dropbear per ssh ?
oltre a un bel passwd
è tutto ?

[giovanni69]

Vorrei fare dei test, tra l'altro mi interesserebbe anche alzare l'snr, vorrei portare la linea da 200/20  ad una 30/3

Collet, sei riuscito ad utilizzare il comando maxdatarate per tagliare la banda gestendo singolarmente l'upstream ed il downstream?

[^NiCo^]

Collet, sei riuscito ad utilizzare il comando maxdatarate per tagliare la banda gestendo singolarmente l'upstream ed il downstream?

Da quello che ho letto cè un file di configurazione per xdsl -> /etc/config/xdsl

 "vi /etc/config/xdsl" e poi modifichi

option maxaggrdatarate '120000'
option maxdsdatarate '100000'
option maxusdatarate '20000'

se ho capito bene maxaggrdatarate va impostato come somma di ds+us, non sono sicuro nell' esempio che ho visto è così @Ansuel ne saprà di più sicuramente.

Inoltre in quel file si dovrebbe poter settare in che modo si allinea il modem, es. impostare solo vdsl2 con profilo 17a o vdsl2 35b (ovviamente se si è in 17a profilo 100mb non si allinea se forzate solo 35b)

Qui invece ci dovrebbe essere la cfg delle porte fxs -> /etc/config/mmpbxbrcmfxsdev (sempre da editare con vi)

Per aggiungere un' altro account voip invece qui -> /etc/config/mmpbxrvsipnet

Non ho ancora provato nulla personalmente, queste sono info pescate in rete, domani spero di testare un pò di cose.

[miki8989]

potresti fare un ping -n 1000 192.168.1.1 e vedere questi lag spike se sono effettivamente rivolti al modem o ad altro ?

questo è il risultato
Risposta da 192.168.0.1: byte=32 durata=5ms TTL=64
Risposta da 192.168.0.1: byte=32 durata=5ms TTL=64
Risposta da 192.168.0.1: byte=32 durata=8ms TTL=64
Risposta da 192.168.0.1: byte=32 durata=1ms TTL=64
Risposta da 192.168.0.1: byte=32 durata=4ms TTL=64

Statistiche Ping per 192.168.0.1:
    Pacchetti: Trasmessi = 53, Ricevuti = 53,
    Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
    Minimo = 1ms, Massimo =  11ms, Medio =  4ms

con il ping rivolto al d7000
Risposta da 192.168.0.1: byte=32 durata=4ms TTL=64
Risposta da 192.168.0.1: byte=32 durata=4ms TTL=64
Risposta da 192.168.0.1: byte=32 durata=6ms TTL=64
Risposta da 192.168.0.1: byte=32 durata=4ms TTL=64
Risposta da 192.168.0.1: byte=32 durata=4ms TTL=64
Risposta da 192.168.0.1: byte=32 durata=6ms TTL=64
Risposta da 192.168.0.1: byte=32 durata=4ms TTL=64

Statistiche Ping per 192.168.0.1:
    Pacchetti: Trasmessi = 70, Ricevuti = 70,
    Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
    Minimo = 1ms, Massimo =  11ms, Medio =  4ms

grazie

[Collet]

Collet, sei riuscito ad utilizzare il comando maxdatarate per tagliare la banda gestendo singolarmente l'upstream ed il downstream?

Si sono riuscito, è abbastanza semplice, con il comando xdsctl configure --maxDataRate e poi la velocità in ds us e ds+us.

Invece non ho ancora provato a disattivare il g.inp, non sono sicuro del comando esatto. Dovrebbe essere xdslctl configure --Ginp  poi va compilato questo campo <0xBitMap-UsDs>, e sinceramente non so come (0x poi?)

[-Mirco-]

Per quanto riguarda la possibilità di abbassare snr  e spegnere UBPO niente vero?

[ironmark99]

...e spegnere UBPO...

Sinceramente mi auguro che non sia possibile, o che se lo fosse questa funzionalità non venga resa pubblica.
Perché seppure io non abbia nulla in contrario a sperimentare, e se uno vuole provare ad alzare o ad abbassare l'SNR, o a disabilitare il G.INP in fondo sta "giocando con la sua linea", andare a mettere le mani su un parametro che mi può "avvantaggiare" a scapito dei vicini di casa, mi pare poco serio e democratico...
Non è che chi si è inventato l'UPBO lo abbia fatto per "cattiveria" o con l'intento di mettere i bastoni tra le ruote ai clienti.
Dirò di più: se si potesse disabilitare il G.INP sarei contento, così chi è convinto (a torto o a ragione) che la sua "esperienza di gioco" ne sia danneggiata, possa verificarlo di persona, e decidere da sé (effetto placebo o meno, non mi interessa) se mantenerlo attivo o meno.
Con l'UPBO invece è troppo facile essere "tentati" dal diminuirlo (anche se magari ci si guadagna solo un po' di margine visti i limiti di banda US imposti dal profilo), con la sensazione che "così la mia linea è più stabile" (magari per recuperare il G.INP disabilitato).

[TeddyRaspin76]

@ironmark99

Concordo pienamente. Tra l'altro levando il G.INP a me non cambia una mazza in termini di latenza. Pingo sempre il primo hop tra 3 e 4 ms e sui servers italiani (NGI ad esempio) pingo uguale, quindi a che pro levarlo

Sarebbe invece carino poter agire sull'SNR come avviene in ADSL, ma tale comando appunto funziona solo ed esclusivamente per le connessioni ADSL, visto che l'SNR in VDSL è calcolato su più bande, sia in down che in up.