[Thread ufficiale] amod - firmware modificato per DGND4000, DGN3500, DGN2200V3/V4

[danyus]

ma il delta mi sottrae banda anche al 100% , cosa che teoricamente non dovrebbe, o sbaglio?

es.
lascio tutto invariato faccio un paio di speedtest (per conferma valori) e mi segnala 16mb
inserisco 10%delta (e sto nel range 100%) scende a 15mb

non credo che dovrebbe limitare anche il 100%

Per questo suggerivo di prendere (come rate di default totale) il valore della portante grezzo e sottrargli all'inizio l'overhead e da li semplicemente le percentuali.

[alfonsor]

in questo momento sono connesso secondo i valori del driver atm a 21.461 Mbs ↓ 1.084 Mbs ↑

ovviamente 21461 mica sono reali; infatti scarico a circa 17500 kbits

come faccio a comunicare allo script che quella è la mia velocità? mica ad ogni connessione posto stare a dirglielo; metto 5 o 10 % di delta e via

se metto 0 di delta, imposto la classe 1 a 100 min e 100 max e lo uso come default, speedtesto o altri test di download qualsiasi vanno allo stesso identico valore che lo script sia in funzione o non sia in funzione

se metto delta a 5% o 10 il risultato è lo stesso, perché il 5% di 21 mega è circa un mega e quindi i calcoli saranni fatti su 18 o 19 mega, quando io vado a 17 e spiccioli

non esiste alcuna possibilità di inventarsi un metodo per dare allo script la reale banda di down upload, per cui bisogna accontentarsi di parametri ragionevolmente calcolati

[alfonsor]

Originariamente inviato da labodj

Ho visto che quando non si connette da questo messaggio: LCP: timeout sending Config-Requests

potresti vedere quale causa è tra queste
http://pptpclient.sourceforge.net/ho...ml#lcp_timeout

e magari usare qualche opzione tra queste
http://www.tldp.org/HOWTO/PPP-HOWTO/options.html

[danyus]

Originariamente inviato da alfonsor

in questo momento sono connesso secondo i valori del driver atm a 21.461 Mbs ↓ 1.084 Mbs ↑

ovviamente 21461 mica sono reali; infatti scarico a circa 17500 kbits

come faccio a comunicare allo script che quella è la mia velocità? mica ad ogni connessione posto stare a dirglielo; metto 5 o 10 % di delta e via

se metto 0 di delta, imposto la classe 1 a 100 min e 100 max e lo uso come default, speedtesto o altri test di download qualsiasi vanno allo stesso identico valore che lo script sia in funzione o non sia in funzione

se metto delta a 5% o 10 il risultato è lo stesso, perché il 5% di 21 mega è circa un mega e quindi i calcoli saranni fatti su 18 o 19 mega, quando io vado a 17 e spiccioli

non esiste alcuna possibilità di inventarsi un metodo per dare allo script la reale banda di down upload, per cui bisogna accontentarsi di parametri ragionevolmente calcolati

a me non va così

io ho portante (ad esempio adesso) di 18340 se a questo sottrai l'overhead (che e' un valore costante nelle adsl a seconda del protocollo usato.... pppoa ha meno overhead di pppoe ma siamo tra il 12 e il 14 %) quindi nel mio caso con pppoa 12% hai 16139(e su speedtest io vado pressoche' a quella velocità
su pppoe l'overhead e' intorno al 14%

in ogni caso questo e' lo scenario che invece a me si verifica

limiter disattivato.... speedtest 16mila e rotti

limiter attivato senza nessuna regola(quindi default 100%) 16mila e rotti

limiter attivato con il delta a 10% 14mila e rotti
quindi il delta sta influendo sul valore finale(almeno nel mio caso)

per questo chiedevo se non fosse possibile comunicare (ad ogni eventuale retrain) invece che il valore reale di portante(esclusivamente per il limiter) il valore della portante meno l'overhead.

[alfonsor]

ad ogni retrain lo script viene rilanciato

quando lo script viene rilanciato, rilegge i valori di downstream e upstream che in quel momento sono quelli attuali

ascolta...

quei valori servono per avere calcoli corretti

la banda considerata, per dire per il downstream è semplificando
drate="download rate come dice il driver / 1000" kbit
drate=drate*(100-RDELTA)/100

questo ultimo drate è quello passato al qos per fare i calcoli vari

ci sono diverse possibilità:
- metto i campi di rate dove uno può specificare a mano; mette i valori che gli pare, RDELTA non viene considerato; che succede? succede che i valori non saranno mai quelli davvero reali

- uno mette rdelta a 0; i valori di down e up saranno quelli giusti davvero, ma non quelli reali; succede che se dai il 50% della banda ad un host, ti ritrovi che quello non ha il 50% della banda reale, ma molto di più

se pensi che posso passare alla classe di default i valori senza il delta, mi dispiace deluderti ma non posso; la prima volta che si passa il valore per dire di downstream è al momento della creazione della classe 1:1

la classe di default è attaccata alla classe 1:1 e quindi non posso specificargli un rate maggiore della classe a cui è attaccata

quello che posso provare è dargli come ceil il downstream senza DELTA, ma anche qui non so se una classe figlio possa avere un ceil maggiore del rate della classe padre

devi tenere a mente una cosa però in tutto questo:
perché mi ero sempre rifiutato di fare il QoS limitatore?

uno degli svariati motivi era anche che su una pagina web semplificata non puoi mettere tutti i casi che tutti gli utenti vorrebbero

con questo qos puoi specificare le porte, puoi specificare i TOS, puoi fare praticamente quello che vuoi, ma in uno script non su una pagina web

uno offre gli strumenti, l'utente si fa lo script esattamente come desidera, come gli serve, calcolando i valori esattamente come gli conviene, perché è come "conviene a lui" non come "dovrebbe essere naturale"

nei qos si applica sempre un delta in qualsiasi qos, che te lo facciano specificare o no, ci deve essere un delta altrimenti i calcoli non sono come li vorresti; con il delta i calcoli non sono lo stesso come li vorresti ma un pò meglio

[danyus]

come non detto....
non so per quale motivo ma ho rifatto altre prove(dopo aver riavviato il router per l'ennesima volta) e come prima cosa ho fatto speedtest senza limiter e poi solo con delta attivo al 10% ed e' sempre uguale.

Scusami per l'errore di valutazione, funge perfettamente

va benissimo la scelta della percentuale, invece di inserire i valori manualmente perche' così si ha sempre il valore corretto.

[danyus]

il max che potresti aggiungere forse(considerando che appunto noi dobbiamo eliminare l'overhead) e' quello di mettere nel delta il famoso 12-14%
e' quella la percentuale che da fastidio ai limiters inferiore del 100%
quando uso delta 10% sto quasi perfetto, se uso 15% la classe che ha 100% si ritrova con una piccolissima percentuale in meno di banda.

alla fin fine e' giusto togliere come ragionamento il delta ma e' anche corretto dargli la percentuale giusta che e' QUASI una costante in tutte la adsl a secondo del protocollo di connessione utilizzato

[alfonsor]

ho provato or ora sul 2200V3 a dare alla classe di default valori maggiori della classe 1:1 e ovviamente ho gli errori
HTB: quantum of class 10001 is big. Consider r2q change.
in dmesg

quegli errori non sono gravi, ma vogliono dire che i calcoli che htb farà saranno sballati

quegli errori si possono correggere, ma ugualmente sono forzature, che appunto ogni singolo potrebbe voler fare a mano in un suo script

esattamente come il delta con valori tipo 12.53%

devi pure pensare che il valore che secondo te è perfetto per te, tipo 12% lo è in quell'istante che fai la prova; magari tra dieci minuti o domani non lo è più

uno script qos non è che ti può fare impazzire a regolarlo di giorno in giorno, lo devi usare senza pensieri

[labodj]

Originariamente inviato da alfonsor

potresti vedere quale causa è tra queste
http://pptpclient.sourceforge.net/ho...ml#lcp_timeout

e magari usare qualche opzione tra queste
http://www.tldp.org/HOWTO/PPP-HOWTO/options.html

Nessuna tra quelle, ho attivato il debug e sembra tutto normale.


Andiamo per gradi:
1) Ho messo la .17, e il file options non c'è in /etc/ppp/

2) Durante il kill da queste 3 linee uguali, non c'entrerà nulla ma non sembra proprio bello

iptables: Bad rule (does a matching rule exist in that chain?)
iptables: Bad rule (does a matching rule exist in that chain?)
iptables: Bad rule (does a matching rule exist in that chain?)

EDIT: viene dal comando rc vpn stop, infatti io non uso vpn e ho liberato le risorse ipsec all'avvio, invece di stopparla sempre bisognerebbe controllare che fosse avviata prima, no?

3)Il problema del MTU e MRU, durante la connessione viene ricevuto un primo pacchetto dal dslam che indica quale dovrebbe essere l'mru da impostare, e salvo diversa configurazione nel file options viene impostato a quel valore, probabilmente con dslam marconi in adsl1 vecchi come me non si sa perch+ si riceve questo

rcvd [LCP ConfReq id=0x23 <mru 9178> <auth pap> <magic 0x39000e59>]

quindi il mio dslam chiede di impostare il valore a 9178, che è abbastanza fuori di testa secondo me, per ovviare al problema basta inserire nel file options questo

mtu 1500
mru 1500
-mru

4) Anche questo non sembra particolarmente bello, ma non ho idea da dove venga

RTNETLINK answers: Network is unreachable
ifconfig: SIOCSIFTXQLEN: No such device

5) Ho aumentato gli sleep di rpppoa a 5 e quelli di ip-down-act a 3, e con il file options con solo mru e mtu non sbaglia un colpo (per ora)

[alfonsor]

tutti quegli errori che vedi mica li genero io

li genera rc_apps che sarebbe il mega coso di Netgear che lancia le varie schifenze

di rc_apps (a dire il vero si chiama rc ma in amod è rinominato rc_apps) mica ho i sorgenti

sarà probabilmente basato su qualche rc.c che risale al 1956 e su rc.c dell'ultimo modello di modem

ci trovi di tutto dentro e di più; uso di interfacce inesistenti, lancio di regole di qos ed iptables che non sono possibili, uso di variabili in /proc che non esistono e via dicendo

lo modifico ogni tanto, ma a mano con hexedit; per dire riguardo questo problema, sono stati cambiati tutti i
killall -9 pppd1
in
killall pppd1

questo è tutto quello che posso fare

se qualcuno è capace di fare un reverse engeenering di quel file in C gli regalo una cassa di vino abruzzese doc per Natale

[labodj]

Quindi niente vino per me a natale ho reversato il microcode della cpu nel bios del mio notebook per aggiornarlo una volta, è andato tutto bene, puro esercizio di stile, ma non credo di volermi uccidere nuovamente con l'esadecimale.

Il file options comunque lo potresti inserire in modo che l'mtu inserito dall'utente nell'interfaccia web venga aggiunto come linea all'avvio (e ad ogni cambiamento), saresti sicuro così che il valore non sarà ignorato (si può inserire anche la netmask, in modo che non venga negoziata, tanto è sempre 255.255.255.255)

Credo che allungando leggermente gli sleep insieme al file options (senza l'opzione -ng) il problema si risolva.

netmask 255.255.255.255
lock
mru 1500
mtu 1500
-mru
-detach

Ma poi non ho capito, ma l'interfaccia è ppp1 o ppp0? boh...

Using interface ppp1
Connect: ppp1 <--> 
RTNETLINK answers: Network is unreachable
ifconfig: SIOCSIFTXQLEN: No such device
mtu is <1500> ao->mru is <1500>
Set ppp0 MTU 1500

Ho fatto qualche prova, mtu e mru vengono impostati sull'interfaccia sbagliata a quanto pare... ppp0 al posto di ppp1 (con e senza file options)

[alfonsor]

detach lo toglierei

option non è stato inserito perché esiste il meccanismo over se vuoi che qualcosa appaia in /etc/ basta che lo metti in /etc/amod/conf/over

non devi badare ai messaggi di rc, quelli sono strambi perché fa cose strambe

comunque...

mi sembra che la cosa non funzioni, appena ho tempo e pazienza rimetto tutto come era prima di questi combiamenti del cavolo

[labodj]

A me sembra funzionare a dovere invece.

Dentro over ho messo options

netmask 255.255.255.255
lock
mtu 1500
mru 1500
-mru

Cambiato lo sleep di ip-down act da 1 a 2

Prende la connessione subito in avvio e fa sempre il renew dell'ip...

[danyus]

Originariamente inviato da alfonsor

devi pure pensare che il valore che secondo te è perfetto per te, tipo 12% lo è in quell'istante che fai la prova; magari tra dieci minuti o domani non lo è più

uno script qos non è che ti può fare impazzire a regolarlo di giorno in giorno, lo devi usare senza pensieri

Hai perfettamente ragione infatti proprio per questo lodavo la scelta delle percentuali al posto dell'inserimento manuale di valori

per quanto riguarda il valore da assegnare al delta non capisco perche' tu dica che sia così tanto variabile anche giorno per giorno... avevo studiato un pochino come funzionano le connessioni siano esse pppoa che pppoe, preferendo appunto (ed avendolo verificato) il pppoa in quanto ha minore overhead, che pero' e' appunto praticametne costante. Dipende da alcuni fattori ma per il pppoa siamo SEMPRE intorno a al 12% e per il ppppoe siamo sempre tra il 14 e il 15 %
vabbe' comunque io lo terro impostato al 10% che e' praticamente perfetto per me


Comunque secondo me la versione "definitiva" dovrebbe solo avere la possibilita' di suddividere upload e download e sarebbe perfetta :-)

[alfonsor]

la versione che ho su entrambi i router ora è fatta così

download e upload rate sono sempre specificabili; se li lasci vuoti, usa quelli del driver atm, se ci metti un valore, usa quello

rdelta è un intero tra 0 e 50

c'è tutto l'ambaradan delle classi sia per downstream che per upstream

così mi sembra che ognuno può fare quello che gli pare e piace

---

ho solo un problema che affligge il 2200V3 che non riesco a capire, ma il 2200V3 non è iptables-only come il 3500 e gli impicciamenti che ha forse pesano

senza qos se faccio da telnet dentro il router
ping 192.168.1.100 -s 15000
il tempo medio è 4 secondi (quell'ip è un host della lan)

con il qos è 8 secondi

questo avviene solo se faccio il ping da dentro il router

qualcosa rallenta enormemente il router stesso, tanto che se il qos è attivo il flash non va, perché per caricare il firmware ci mette talmente tanto tempo che va in timeout, quindi devo killare il qos prima di fare il flash

le ho provate tutte ed è davver inspiegabile

la cosa avviene alla prima creazione della classe root, senza che faccio altro

[alfonsor]

per quanto riguarda invece il 3500 e lo stramaledetto pppd sto provando l'ultima cosa prima di rinunciare e tornare indietro a come era prima

prima di fare qualsiasi cosa che riguardi rilanciare la wan, negli script di ppp, attendo che pppd stesso sia morto e stramorto (lo posso fare perché lo script che pppd attende è solo il primo, gli altri sono lanciati con dize che demonizza)

solo dopo che pppd è morto, avvio di nuovo la wan

così dovrebbe essere risolto qualsiasi problema di loop strani per cui pppd viene riavviato mentre ancora non è completamente chiusa un'altra istanza e quindi qualcosa potrebbe non andare giù al modem remoto che fa storie e chiude la connessione

se manco così va, gli possino alle pppoa e chi le ha inventate e pure alle piastre pppoa da sette mega :P

[random566]

@ alfonsor
oggi mi hanno attivato la vdsl nell'altra abitazione e ho subito provato a collegare il 3500 a quella linea dopo aver selezionato ptm e riavviato il router.
ho provato anche con tasklet_ptm, ma il problema è che proprio non si allinea alla portante.
fa continui tentativi ma non si allinea mai.

[alfonsor]

grazie random, era una curiosità che volevo togliermi

[anaka]

Salve a tutti, avrei bisogno di un aiuto per quanto riguarda la possibilità di modificare snr sul DGN2200V4.
Appena preso, ho effettuato l'aggiornamento del firmware con l'amod, ma sull'interfaccia non ho trovato la voce relativa all'snr: ho cercato dappertutto, ma non c'è.
Ho commesso qualche errore? Ho saltato qualche passaggio?
Mi potete dare un consiglio?

[random566]

Originariamente inviato da anaka

Salve a tutti, avrei bisogno di un aiuto per quanto riguarda la possibilità di modificare snr sul DGN2200V4.
Appena preso, ho effettuato l'aggiornamento del firmware con l'amod, ma sull'interfaccia non ho trovato la voce relativa all'snr: ho cercato dappertutto, ma non c'è.
Ho commesso qualche errore? Ho saltato qualche passaggio?
Mi potete dare un consiglio?

sul 2200v4 c'è un'interfaccia web aggiuntiva raggiungibile da http://192.168.0.1:8082 dove ci sono tutte le impostazioni di amod, compresa la variazione del target snr.
ovviamente, nel caso tu avessi cambiato l'indirizzo di default del router, al posto di 192.168.0.1 metti l'indirizzo reale del tuo router.
il nome utente e la password richiesti sono gli stessi dell'interfaccia web principale