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

[alfonsor]

Originariamente inviato da random566

messa anche la 11.0.20 sul 3500.
per il servizio limiter, per pura curiosità, senza fare alcuna configurazione, ho provato a farlo partire, però una volta avviato non c'è modo di fermarlo se non riavviando il router.
al contrario, sul 2200 si avvia e si ferma regolarmente dal pulsante

dopo che premi stop, sembra che non si sia stoppato ma si è stoppato, non cacella un file che indica se è attivo o no e quindi viene riportato sempre come attivo

[alfonsor]

Originariamente inviato da donlimo

ciao alfonso,
volevo ringraziarti per questo splendido firmware. ha cambiato totalmente il mio router!
in ogni caso scrivevo per chiederti, se possibile, e con i tempi che credi, di effettuare una modifica al syslog.

https://www.dropbox.com/s/l4n1ubq6hu...creen.png?dl=0

come puoi vedere dall'immagine il problema è che non viene inviato alcun nome host, tanto meno l'indirizzo ip del router. alla fine lo rintraccio filtrando per "TCP" ma è una cosa fastidiosa. lo faceva anche col firmware netgear.

puoi fare qualcosa a riguardo?

grazie in ogni caso

mi dovresti specificare di quale router parli, di che voce è quella, cioé è una voce presente in syslog generata da cosa?

[alfonsor]

per i possessori del 3500

se dopo un flash, il router si riavvia ma non parte e la luce power lampeggia come se il router fosse in modalità ripristino, vuol dire che qualcosa è andato male durante il flash ed il router se ne accorto e vi offre di caricare il firmware di nuovo attraverso una speciale pagina web

il router in quel momento ha indirizzo 192.168.1.1 quindi per raggiungerlo dovete dare alla eth del computer un indirizzo in quella net, per dire 192.168.1.2

fatto questo si scrive 192.168.1.1 ed appare una pagina web scarna, si indica il firmware e si fa il flash; router recuperato

[danyus]

Originariamente inviato da random566

messa anche la 11.0.20 sul 3500.
per il servizio limiter, per pura curiosità, senza fare alcuna configurazione, ho provato a farlo partire, però una volta avviato non c'è modo di fermarlo se non riavviando il router.
al contrario, sul 2200 si avvia e si ferma regolarmente dal pulsante

confermo quanto riportato.... il servizio non si stoppa
Segnalo un altro bug (o almeno credo tale) :
Non avevo assegnato il range 192.168.0.0/24 alla 100%(pensando fosse gia incluso) e per fare test avevo messo il mio ip nella classe del 30% avviato il servizio testato e perfettamente funzionante. Tolto l'ip dalla classe 30%, (quindi praticamente avevo tutto vuoto), ho riavviato il servizio e avevo ancora limitato a 30%. Ho risolto poi mettendo il range 192.168.0.0/24 alla 100% e riavviando il servizio.
Credo dovesse essere incluso a priori il range totale nella 100% no?


con htb non mi sembra avesse questo comportamento, per curiosità come mai hai scelto hfsc? e' piu' performante?

[alfonsor]

"tutta la LAN" non va specificata da nessuna parte perché viene creata una classe hfsc di default con la banda specificata come default per cui tutti gli ip che non appartengono a qualche classe finiscono li dentro

ci sono tantissime ragioni per cui non mi piaceva il metodo precedente

per riassumere: era un hack che per caso funzionava ma non era la maniera per fare la cosa

semplicemente perché in nessuna documentazione, letteratura, esempio nel mondo su come si applichi un qos ad un dispositivo con due eth una che va verso l'interno LAN ed una che va verso Internet WAN, veniva usata mai la LAN per fare qos verso la WAN

vuol dire che semplicemente alle fondamenta era sbagliato, ma che funzionava per come era fatto il firewall, per tentativi

e operando sulla lan se avevi altre cose, per dire la WLAN guest con un'altra rete e non in bridge con la LAN non la potevi limitare

e via dicendo una catena di comportamenti strani causati dal fatto che "non si fa così"

sul 2200V3 devo usare ancora quel metodo ma cercherò se avrò tempo e fortuna di usare ifb e una maniera canonica

la maniera canonica è questa: se il qos è fatto su quanto entra ed esce dalla wan, il qos non va fatto sulla lan

[danyus]

Originariamente inviato da alfonsor

"tutta la LAN" non va specificata da nessuna parte

ok ma il bug che ti ho segnalato c'e' esclusivamente quando non specifico "tutta la lan"

ho testato nuovamente :
metto il mio ip nella classe 30 e riavvio il servizio, mi limita la banda al 30%
tolgo il mio ip dalla classe 30 e riavvio il servizio, la banda resta limitata al 30%

[alfonsor]

mahhh io sto provando e riprovando qui

metto l'ip di questo computer in qualche classe, premo restart, faccio un speedtest test e ho la banda di quella classe, lo cancello da quella classe premo restart e ho la banda di default, cinque volte di seguito con varie limitazioni percentuali di banda provato e riprovato ed il risultato è quanto mi aspetto che sia

[danyus]

ok dopo ulteriori test ho scoperto come riprodurre(almeno nel mio caso) il bug che ti segnalavo.

MIO ip rispettivamente nel 30% down e up , start (verifica banda limitata) tutto ok!

Tolgo l'ip(lascio vuoto) solo dal 30% down(ma resta 30% in up). save and restart. Banda ancora limitata anche in down.

a me succede questo.
verificato piu' volte.

[labodj]

Alfonsor ti aggiorno sul discorso delle riconnessioni in pppoa
con la .20 se do restart la wan rinnova sempre il suo ip, se la wan viene interrotta dalla piastra viene recuperata poi in automatico, se perdo la portante viene recuperata e la wan ripristinata, tutto perfetto a parte una cosa:
quando avvio il router da spento (o se riavvio) 9 volte su 10 non si connette in automatico alla wan, prende la portante ma la wan non parte in automatico, parte nel momento in cui io premo start sull'interfaccia.

Se vuoi una mia idea questa cosa succede perchè qualche piastra ha bisogno di un po' di secondi da quando la portante viene trovata a quando si può far partire una connessione wan.

Quindi secondo me le soluzioni possibili sono 2, o fai partire da subito quello script che prova a connettersi finchè la wan non ha stato up, oppure aspettare 5 secondi ogni volta che si aggancia la portante prima di far partire la wan.

[Jacker]

Originariamente inviato da labodj

Alfonsor ti aggiorno sul discorso delle riconnessioni in pppoa
con la .20 se do restart la wan rinnova sempre il suo ip, se la wan viene interrotta dalla piastra viene recuperata poi in automatico, se perdo la portante viene recuperata e la wan ripristinata, tutto perfetto a parte una cosa:
quando avvio il router da spento (o se riavvio) 9 volte su 10 non si connette in automatico alla wan, prende la portante ma la wan non parte in automatico, parte nel momento in cui io premo start sull'interfaccia.

......

Confermo la problematica da router spento e da riavvio.

[alfonsor]

arg a tutti e due i post

sul qos, mi accorgo ora che era studiato per non avere down ed up separate, visto che marca i pacchetti con lo stesso handle, cioé numero e quando finiscono nella chain mark hanno un unico handle e prendono la classe di quello handle, vediamo che si può fare...

per il pppoa 7 mega non so davvero più che pesci prendere e quindi mi conviene andare a dormire, perchè questa volta ero sicuro che le cose fossero fatte come si deve; al boot non manda su la WAN? ma come è possibile crispino da capalbio peccatore di tutti i gironi non lo so proprio

la prima volta che il router fa una connessione atm, la wan viene mandata su nello script /etc/xdslrc.sh che viene chiamato direttamente da dsl_cpe_control quando accade qualcosa alla connessione ATM

    case "$DSL_INTERFACE_STATUS" in
      "UP")
        echo "Showtime" >/tmp/adsl/state
        cp /proc/uptime /tmp/adsl/line_uptime
        echo $DSL_DATARATE_US_BC0 >/tmp/adsl/upstream
        echo $DSL_DATARATE_DS_BC0 >/tmp/adsl/downstream
        if [ -e /tmp/wan_started ]; then
          rc wan restart >/dev/null 2>&1 &
        else
          rc wan start >/dev/null 2>&1 &
          touch /tmp/wan_started
        fi
        ;;

la differenziazione tra "la wan è la prima volta che va su" e "la wan è andata su almeno una volta" è fatta dal primo firmware netgear per il 3500 perché evidentemente rc wan start va usato solo la prima volta mentre rc wan restart va usato in seguito; non avendo i sorgenti di rc, ho sempre ritenuto meglio lasciarla così

quindi quando la ATM va su la prima volta, lo script semplicemente fa un
rc wan start

rc wan start lancia le sue cose tra cui pppd

non vedo come ci possa essere bisogno di una pausa, visto che da sempre fa così quello script e non c'è mai stata una pausa

inoltre, lo script che prova di continuo a rilanciare la wan è sempre lanciato, se la connessione fallisce, anche al primo boot e prima connessione


bo e mahhh

[alfonsor]

se qualcuno di voi due ha la seriale montata, dovrebbe fare un boot da seriale e loggare almeno quale errore e comportamento strano ha rc wan start e pppd che lancia per conoscere almeno l'errore

comunque potreste provare a modificare lo sleep che è alla fine di /etc/ppp/ip-rwan da sleep 1 in sleep 10 e vedere se cambia qualcosa

siccome questo avviene al boot, dovreste mettere la macro modificata in
/etc/amod/conf/over/ppp/ip-rwan

e fare un reboot

così verrà usata quella modificata; magari un solo secondo se al boot ci sono problemi di wan che non va up è troppo poco

magari si potrebbe mettere anche qualcosa tipo

exec >/tmp/wan_log all'inizio della macro, per avere il log di quello che accade in /tmp/wan_log, dopo avere anche tolto il >/dev/null 2>&1 dal comando rc wan restart

[rixxardo1]

Originariamente inviato da alfonsor

bastava che

se la luce lampeggiava da sola, mettevi il computer sotto 192.168.1.0/24, andavi su 192.168.1.1 e ti sarebbe apparsa una pagina per caricare il firmware

se la luce non lampeggiava da sola, la procedura tenere premuto il tasto di reset mentre si accende il router la faceva lampeggiare quindi potevi usare la utility netgear solita

non c'era bisogno di mandare in garanzia; il 3500 non è il 2200V3

Be cosa devo dirti, GRAZIE, il router ancora non era partito, ho riaperto il pacco e seguito le tue istruzioni.
FUNZIONA tutto.
GRAZIE

[alfonsor]

mi fa piacere, perché il 3500 ha la grande virtù che per brikkarlo ti devi mettere proprio a volerlo fare; mi è successo diverse volte, ma solo perché provavo kernel del tutto fuori di testa, mentre i flash andati a male si risolvono sempre; per quanto riguarda se esiste un limite alle riscritture, be certo che c'è, non so quale sia, però siccome il mio avrà avuto oramai migliaia di riscritture, direi che il 3500 diventa obsoleto di suo prima di morire per memoria rovinata...

---

per il problema della pppoa, mi dite per cortesia normalmente, quando al boot la wan va su, quanti secondi ci mette la wan ad andare su rispetto alla ATM? Cioé quale è la differenza tra "Link uptime" e "WAN uptime"? E' nell'ordine di meno di 10 secondi o superiore ai 30?

[labodj]

Alfonso non ho la seriale e non ho trovato una guida su come potrei ricavarne una dal pcb del router.

In ogni caso ho creato e dato permessi 777 a /etc/amod/conf/over/ppp/ip-rwan/

#!/bin/sh

export PATH=/usr/sbin

# check if we have no ATM or we have WAN
# if so, we are done

exec >/tmp/wan_log

check() {
  [ -e /tmp/adsl/line_uptime ] || [ -e /tmp/amod_no_rc ] || exit
  amodfunc wanip >/dev/null && exit
}

# wait for pppd to die or kill it
i=0; while [ $i -lt 8 ]; do
  check
  killall -0 pppd$1 || break
  i=$((i+1))
  sleep 1
done
killall -9 pppd$1 || break

# try hard to restart WAN, but with timeout
i=0; while [ $i -lt 16 ]; do
  check
  rc wan restart
  check
  i=$((i+1))
  sleep 10
done

riavvio adesso e vediamo cosa logga

EDIT: ti direi volentieri quale è la differenza, il problema è che va su una volta ogni mai

EDIT 2: ho riavviato con la modifica e magia delle magie si è connesso da solo, la differenza tra link e wan è di 6 secondi

[alfonsor]

quando non va su, quindi quasi sempre, mi dici se in ps si trova il processo

{ip-up-retry} /bin/sh /etc/ppp/ip-up-retry 30

lo trovi per dire con

ps | grep "[{]ip-up-retry}"

[labodj]

Originariamente inviato da alfonsor

quando non va su, quindi quasi sempre, mi dici se in ps si trova il processo

{ip-up-retry} /bin/sh /etc/ppp/ip-up-retry 30

lo trovi per dire con

ps | grep "[{]ip-up-retry}"

Leggi il mio edit sopra, ho riavviato di nuovo, connesso subito e sempre 6 secondi. Tuttavia il file di log non viene creato, non c'è il file /tmp/wan_log

EDIT: Scusa alfonso... probabilemte le ultime mie prove non fanno testo, sono tornato al file "normale" e riavviando si connette sempre, si vede che la piastra in questo momento è molto happy, in ogni caso sempre 6 secondi

[alfonsor]

sinceramente a questo punto, per quanto riguarda la prima volta che si va online non riesco a capire le differenze, per farla breve, tra come funzionava in amod 9 e come funziona in amod 10

cioé, la prima volta che si va online non ci dovrebbero essere differenze

[alfonsor]

e riproviamo ...
http://alfie.altervista.org/amod/dow...1.0.21.img.zip

entrambe le problematiche degli ultimi post sono state affrontate

il limiter ora dovrebbe saper distinguere le classi down da quelle up
per il limiter sono state aggiunte due caratteristiche:
1. wan txqueuelen; questa non è propriamente una cosa del qos, ma viene messa qui per convenienza; è la lunghezza in pacchetti di misura MTU della coda di uscita; di default è 3; quanto deve essere lunga? dipende; più lunga è, meno pacchetti sono persi in caso di congestione, ma la latenza diventa maggiore; per alcune cose è meglio un valore per altre un altro; per dire, come da esempio dello help, se uno ha una banda in upload di 1000 Kbps, se la MTU è 1500 e txqueuelen è 20, un pacchetto potrebbe rimanere anche 4 secondi nella coda prima di essere spedito ( 1000000/8 / (1500*20) )

questa cosa va bene per alcuni utilizzi, non va bene per altri, tipo una telefonata in VOIP ha pacchetti che diventano obsoleti dopo pochi millisecondi

un valore di 0 vuol dire "non la toccare"

2. prima di inserire qualsiasi regola iptables, dopo aver creato le classi del qos, si controlla se esista il file /etc/amod/conf/limiter.usr; il file non deve essere eseguibile né iniziare per #!/bin/sh e può contenere liste di regole iptables

un esempio

mettiamo che abbiate lo host 192.168.0.2 con banda in download al 30% ma su cui guardate spesso video da connessioni alla porta 8080 e volete avere banda piena per questo; mettiamo che la classe 1 abbia banda in download al 100%; la regola

iptables -t mangle -A ingress_chain -d 192.168.0.2 -p tcp --sport 8080 -j MARK --set-mark 5

vi metterà tutte le connessioni tcp di 192.168.0.2 verso la porta 8080 di qualcosa su Internet nella classe 5 (che è la 1 per il dowload)

===

per quanto riguarda il ppp

ho scelto una soluzione radicale: se il problema è al boot vuol dire che pppd non è ancora avviato, la connessione ppp non riesce, pppd esce, ma non chiama alcuna macro di wan down perché la wan non è mai andata up né esiste che io sappia alcuna macro che venga chiamata in quel caso; allora, alla connessione atm viene invocato direttamente lo script che prova e riprova a connettere la wan; ora è possibile definire un timeout per i tentativi (che sono in ogni caso sempre sospesi dopo circa 10 minuti) in Various / amod ; per le connessioni pppoa a quanto pare più rognose, il minimo usato è 3 secondi, altrimeni il minimo è 1 secondo

[danyus]

tra poco lo aggiorno... grazie per la celerità con cui correggi i bug :-D

comunque sarà il caldo ma non ho capito bene il fatto di txqueuelen

dici che piu' e' alto il valore piu' , maggiore "può" diventare la latenza in caso di congestione per non perdere pacchetti, facendo l'esempio ( 1000000/8 / (1500*20) )
e qui mi trovo data l'equazione con un risultato di 4(approssimato)

ma se al posto di 20 avessi messo 3 il risultato sarebbe stato 27.7 circa
mi son perso qualcosa?
Anche perche' leggendo alcune cose riguardo txqueuelen indicano valori all'ordine di 1000 o 10000(ben piu' grandi)

Ho il timore che il gran caldo mi abbia fuso il cervello ...
scherzi a parte volevo giusto capire meglio il funzionamento prima di utilizzarlo, oppure lo lascio di default.