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

[kilyan82]

questa versione a me funziona malissimo, non riesco mancoa toccare l'snr, che la velocita' non mi supera 90KB/s.
Il massimo a cui arrivo qua è 720 senza toccare snr.
Voi siete tutti in adsl2 e superiori, magari funziona male solo con le adsl1,boh!

[random566]

a me invece sembra che funzioni meglio. forse è come dici tu, funziona meglio in adsl2+.
però è difficile valutare tutto ciò, le condizioni della linea sono estremamente variabili.
magari poi alfonsor ci dice che sulla parte adsl non cambia niente rispetto alle versioni precedenti.

[labodj]

Boh... a me funzionano tutte uguali lato adsl.
Sono in adsl1 ma non noto nessunissima differenza tra le versioni dalla 9.1.8.4. alla 9.1.9.4

[alfonsor]

ragazzuoli il fatto è questo

a me, inteso come scopo di fare due firmware, di come va la linea, non me ne importa niente :P

messe le impostazioni ADSL, il resto sono affari dell'utente

e mo capisco perché le distro grandi, openwrt, dd-wrt, tomato, evitano come la peste i modem...

perché altrimenti impazziscono dietro "alla linea"

sul serio, questo è un router, fa da router, offre servizi, non fa solo connessioni

errori adsl, ma avete presente che basta che un motore sia acceso vicino alla cabina a cui il filo di casa si allaccia per avere un infernale rumore di fondo che abbatte tutto? e magari sto le ore a controllare cosa possa essere andato male

non fate così su...

[kilyan82]

infatti io non sto dicendo che è colpa tua, ma me ne torno alla versione che mi funzionava meglio

[gastro]

Finalmente ho letto tutto il thread.
Alfonsor mi perdonerai se continuo il thread da questa parte:
Mi hai scritto:

il qos di amod, per cui esiste un thread apposito, non permette di limitare la banda, è basato su altre finalità e considerazioni, e cerca di adoperare la banda per fare andare un pò tutti bene, a seconda delle priorità assegnate

puoi ovviamente usare il tuo script, prendendo la configurazione salvata in quella pagina ed adattandola ai tuoi voleri

per dire, nel file /www.eng/langs/rcS2 che viene eseguito alla fine del boot, puoi copiare un tuo file chiamato qos.hfsc in /etc e quando il qos viene attivato, viene lanciato il tuo file, dove fai quello che ti pare

Ho provato a lanciare nuovamente lo script con il comando "exec shaping" ma mi si chiude immediatamente la connessione telnet o ssh che sia.

Lo script che limita la banda per un certo range è il seguente, funziona solamente con la banda in download e non con quella in upload e ancora non ho capito perchè (cmq funzionava e lo ricopio anche per l'altro utente che ha un problema simile al mio)
Il problema è che ora il comando TC sembra non funzionare a dovere, ed infatti non si riesce a dare il comando che tu consigliavi per migliorare la connessione durante download pesanti, ovvero

tc qdisc add dev ppp1 root tbf rate 950kbit latency 50ms burst 1540

Questo invece è il mio scriptino

#!/bin/bash
#
#  tc uses the following units when passed as a parameter.
#  kbps: Kilobytes per second
#  mbps: Megabytes per second
#  kbit: Kilobits per second
#  mbit: Megabits per second
#  bps: Bytes per second
#       Amounts of data can be specified in:
#       kb or k: Kilobytes
#       mb or m: Megabytes
#       mbit: Megabits
#       kbit: Kilobits
#  To get the byte figure from bits, divide the number by 8 bit
#

#
# Name of the traffic control command.
TC=/sbin/tc

# The network interface we're planning on limiting bandwidth.
IF=br0             # Interface

# Download limit (in mega bits)
DNLD=150kbit          # DOWNLOAD Limit

# Upload limit (in mega bits)
UPLD=80kbit          # UPLOAD Limit

# IP address of the machine we are controlling
IP=192.168.0.152     # Host IP

# Filter options for limiting the intended interface.
U32="$TC filter add dev $IF protocol ip parent 1:0 prio 1 u32"

start() {

#aggiungo init
modprobe sch_cbq
modprobe cls_u32
modprobe sch_sfq

# We'll use Hierarchical Token Bucket (HTB) to shape bandwidth.
# For detailed configuration options, please consult Linux man
# page.

$TC qdisc add dev $IF root handle 1: htb default 30
$TC class add dev $IF parent 1: classid 1:1 htb rate $DNLD
$TC class add dev $IF parent 1: classid 1:2 htb rate $UPLD
$U32 match ip dst $IP/29 flowid 1:1
$U32 match ip src $IP/29 flowid 1:2

# The first line creates the root qdisc, and the next two lines
# create two child qdisc that are to be used to shape download
# and upload bandwidth.
#
# The 4th and 5th line creates the filter to match the interface.
# The 'dst' IP address is used to limit download speed, and the
# 'src' IP address is used to limit upload speed.

}

stop() {

# Stop the bandwidth shaping.
$TC qdisc del dev $IF root

}

restart() {

# Self-explanatory.
stop
sleep 1
start

}

show() {

# Display status of traffic control status.
$TC -s qdisc ls dev $IF

}

case "$1" in

start)

echo -n "Starting bandwidth shaping: "
start
echo "done"
;;

stop)

echo -n "Stopping bandwidth shaping: "
stop
echo "done"
;;

restart)

echo -n "Restarting bandwidth shaping: "
restart
echo "done"
;;

show)

echo "Bandwidth shaping status for $IF:"
show
echo ""
;;

*)

pwd=$(pwd)
echo "Usage: tc.bash {start|stop|restart|show}"
;;

esac

exit

Detto questo, le domande sono:
1) E' normale che in questo momento il mio scriptino non funzioni visto che usa TC?
2) Verrà fixato?
3) ho cercato ma non ho trovato dove ti chiedevo se era possibile affiancare a p910nd anche un qualcosa che faccia funzionare il tutto con airprint, non mi ricordo più la tua risposta
4) Anche per me puoi togliere wsscmd... o come diavolo si chiama... alla fonte... fa solo casino e rendi il firmware più pulito

P.S. Che te lo dico a fare... sei un mito... appassionato, competente, educato e paziente... il top!
Se hai notato ti ho spalleggiato anche nel thread sul forum netgear

Carlo

[Varg87]

Ho appena fatto un test. Ho giocato una mezz'oretta online con entrambi i firmware usando prima il 9.1.9.4 e poi il 9.1.8.4 (ovviamente tenendo invariati gli altri parametri).
Col primo ho ottenuto più di 400 errori mentre col secondo 150 circa. Sarà magia nera, sarà effetto placebo ma con il vecchio a me sembra migliore la situazione con la mia linea.
Appena riesco rieseguo il test entrando nello stesso server visto che stavolta sono entrato in due server a caso (anche se pingavo 40 verso entrambi).

Alfonso, nessuno ti sta incolpando ma se a qualcuno funziona meglio un firmware rispetto ad un altro un motivo ci sarà, non può essere un caso. Nessuno ti sta chiedendo di indagare o di risolvere problemi che si verificano solo in determinate situazioni/linee o che entrano nel campo del paranormale. Comunque sia eseguirò altri test cercando di limitare il più possibile le variabili e se dovesse risultare migliore il vecchio terrò quello e amen.

[random566]

messa la v.1.0.0 sul 2200v3, ho notato che è stato risolto il piccolo bug che indicava il margine di rumore in upstream sulla pagina di stato in modo errato (non lo avevo nemmeno segnalato, dato che era insignificante).
nel changelog c'è scritto "openvpn fix", ma per curiosità, cosa non andava in openvpn? non ho avuto modo di provare la modalità tap, però a me funzionava anche prima e continua a funzionare ottimamente anche con il nuovo firmware.

[PuNkEtTaRo]

Originariamente inviato da labodj

Boh... a me funzionano tutte uguali lato adsl.
Sono in adsl1 ma non noto nessunissima differenza tra le versioni dalla 9.1.8.4. alla 9.1.9.4

Stessa situazione qui...mai notato differenze tra un firmware e l'altro lato ADSL.

[alfonsor]

Originariamente inviato da kilyan82

infatti io non sto dicendo che è colpa tua, ma me ne torno alla versione che mi funzionava meglio

ma il problema non è se è colpa mia o no

ma magari fosse colpa mia, saprei cosa fare!

il problema è che ieri ho perso mezzo pomeriggio a cercare di capire cosa potesse essere e non sono giunto a niente perché non c'è alcuna differenza; anche in questo momento sto confrontando i kernel usati, millimetro per millimetro e non c'è nessuna differenza

guarda funziona così:

all'avvio, prima che si lanci il programmone infineon che fa la connessione adsl, viene invocata un affarino che setta le opzioni utente, in particolare il firmware scelto; questo affarino è identico tra i vari firmware, diciamo dal 8.4 in su è uguale identico

quindi viene lanciato il programmone infineon di cui non ho i sorgenti quindi è sempre quello da sempre

questo fa la sua connessione e sono cavoli suoi

quello che qui potrebbe intervenire è roba di firewall e QoS integrato negli affari netgear; ma da quel firmware ad oggi non è cambiato manco un modulo; non è cambiato come si lanciano i moduli, non è cambiato niente

allora?

non lo so

ma usate wait for tx desc? quello era per prova, non usatelo

[alfonsor]

Originariamente inviato da random566

messa la v.1.0.0 sul 2200v3, ho notato che è stato risolto il piccolo bug che indicava il margine di rumore in upstream sulla pagina di stato in modo errato (non lo avevo nemmeno segnalato, dato che era insignificante).
nel changelog c'è scritto "openvpn fix", ma per curiosità, cosa non andava in openvpn? non ho avuto modo di provare la modalità tap, però a me funzionava anche prima e continua a funzionare ottimamente anche con il nuovo firmware.

sul 3500 in modalità tap non prendeva la maschera dei peer che è necessaria, non settava bene l'indirizzo, dovendo andare indietro alla versione 2.2 di openvpn, non si riusciva a cogliere esattamente il peer connesso, in modalità udp dava "connesso" anche se c'era solo un tentativo di connessione, in modalità tap non settava bene l'interfaccia e qualche altra cosa

anche però così a volte il client se stoppato senza che si è connessi blocca il router, ma questo non so proprio cosa possa essere

[alfonsor]

Originariamente inviato da gastro

Finalmente ho letto tutto il thread.
Alfonsor mi perdonerai se continuo il thread da questa parte:
Mi hai scritto:




Ho provato a lanciare nuovamente lo script con il comando "exec shaping" ma mi si chiude immediatamente la connessione telnet o ssh che sia.

Lo script che limita la banda per un certo range è il seguente, funziona solamente con la banda in download e non con quella in upload e ancora non ho capito perchè (cmq funzionava e lo ricopio anche per l'altro utente che ha un problema simile al mio)
Il problema è che ora il comando TC sembra non funzionare a dovere, ed infatti non si riesce a dare il comando che tu consigliavi per migliorare la connessione durante download pesanti, ovvero

tc qdisc add dev ppp1 root tbf rate 950kbit latency 50ms burst 1540

Questo invece è il mio scriptino

#!/bin/bash
#
#  tc uses the following units when passed as a parameter.
#  kbps: Kilobytes per second
#  mbps: Megabytes per second
#  kbit: Kilobits per second
#  mbit: Megabits per second
#  bps: Bytes per second
#       Amounts of data can be specified in:
#       kb or k: Kilobytes
#       mb or m: Megabytes
#       mbit: Megabits
#       kbit: Kilobits
#  To get the byte figure from bits, divide the number by 8 bit
#

#
# Name of the traffic control command.
TC=/sbin/tc

# The network interface we're planning on limiting bandwidth.
IF=br0             # Interface

# Download limit (in mega bits)
DNLD=150kbit          # DOWNLOAD Limit

# Upload limit (in mega bits)
UPLD=80kbit          # UPLOAD Limit

# IP address of the machine we are controlling
IP=192.168.0.152     # Host IP

# Filter options for limiting the intended interface.
U32="$TC filter add dev $IF protocol ip parent 1:0 prio 1 u32"

start() {

#aggiungo init
modprobe sch_cbq
modprobe cls_u32
modprobe sch_sfq

# We'll use Hierarchical Token Bucket (HTB) to shape bandwidth.
# For detailed configuration options, please consult Linux man
# page.

$TC qdisc add dev $IF root handle 1: htb default 30
$TC class add dev $IF parent 1: classid 1:1 htb rate $DNLD
$TC class add dev $IF parent 1: classid 1:2 htb rate $UPLD
$U32 match ip dst $IP/29 flowid 1:1
$U32 match ip src $IP/29 flowid 1:2

# The first line creates the root qdisc, and the next two lines
# create two child qdisc that are to be used to shape download
# and upload bandwidth.
#
# The 4th and 5th line creates the filter to match the interface.
# The 'dst' IP address is used to limit download speed, and the
# 'src' IP address is used to limit upload speed.

}

stop() {

# Stop the bandwidth shaping.
$TC qdisc del dev $IF root

}

restart() {

# Self-explanatory.
stop
sleep 1
start

}

show() {

# Display status of traffic control status.
$TC -s qdisc ls dev $IF

}

case "$1" in

start)

echo -n "Starting bandwidth shaping: "
start
echo "done"
;;

stop)

echo -n "Stopping bandwidth shaping: "
stop
echo "done"
;;

restart)

echo -n "Restarting bandwidth shaping: "
restart
echo "done"
;;

show)

echo "Bandwidth shaping status for $IF:"
show
echo ""
;;

*)

pwd=$(pwd)
echo "Usage: tc.bash {start|stop|restart|show}"
;;

esac

exit

Detto questo, le domande sono:
1) E' normale che in questo momento il mio scriptino non funzioni visto che usa TC?
2) Verrà fixato?
3) ho cercato ma non ho trovato dove ti chiedevo se era possibile affiancare a p910nd anche un qualcosa che faccia funzionare il tutto con airprint, non mi ricordo più la tua risposta
4) Anche per me puoi togliere wsscmd... o come diavolo si chiama... alla fonte... fa solo casino e rendi il firmware più pulito

P.S. Che te lo dico a fare... sei un mito... appassionato, competente, educato e paziente... il top!
Se hai notato ti ho spalleggiato anche nel thread sul forum netgear

Carlo

non ho capito bene carlo, sarà fixato cosa?

non è che posso fixare gli script altrui

tu puoi lanciare quello che ti pare come qos, ci sono tutti i moduli kernel immaginabili, al boot puoi sostituire completamente pure quello che appare andando sul link QoS, basta che ti fai la tua qos.cgi e la copi dentro /www.eng/langs/rcS2 in /etc

cioé puoi fare tutto, ma non è che siccome lo script per qualche ragione non ti funziona è da fixare altro

[kilyan82]

Originariamente inviato da alfonsor

ma il problema non è se è colpa mia o no

ma magari fosse colpa mia, saprei cosa fare!

il problema è che ieri ho perso mezzo pomeriggio a cercare di capire cosa potesse essere e non sono giunto a niente perché non c'è alcuna differenza; anche in questo momento sto confrontando i kernel usati, millimetro per millimetro e non c'è nessuna differenza

guarda funziona così:

all'avvio, prima che si lanci il programmone infineon che fa la connessione adsl, viene invocata un affarino che setta le opzioni utente, in particolare il firmware scelto; questo affarino è identico tra i vari firmware, diciamo dal 8.4 in su è uguale identico

quindi viene lanciato il programmone infineon di cui non ho i sorgenti quindi è sempre quello da sempre

questo fa la sua connessione e sono cavoli suoi

quello che qui potrebbe intervenire è roba di firewall e QoS integrato negli affari netgear; ma da quel firmware ad oggi non è cambiato manco un modulo; non è cambiato come si lanciano i moduli, non è cambiato niente

allora?

non lo so

ma usate wait for tx desc? quello era per prova, non usatelo

no, mai usato quello

[trim_de_brim]

domanda stupida
ma non è che è cambiato il meccanistmo di controllo dell'errore?

[alfonsor]

gli errori sono letti dal driver adsl; no, non è cambiato nulla in riguardo, almeno che mi ricordi

[alfonsor]

per quelli con i problemi, provatemi questo
http://www.mediafire.com/?x5r4j9du55y540a

[kilyan82]

Originariamente inviato da alfonsor

per quelli con i problemi, provatemi questo
http://www.mediafire.com/?x5r4j9du55y540a

messa cosa hai cambiato?

[alfonsor]

ho eliminato molte modifiche fatte al kernel negli ultimi tempi; modifiche irrilevanti per la maggior parte dei casi; ho inoltre tolto il supporto a layer7 del qos, ora è lungo a spiegare perché

è giusto una prova

[Varg87]

Mah. Con il 9.1.8.4 gli errori mi son saliti a 2000 in 5 ore di connessione e un'ora/ora e mezza di gioco. A sto punto è tutto casuale.
Però è strano che appena messi dessero risultati diversi.

[trim_de_brim]

Originariamente inviato da alfonsor

gli errori sono letti dal driver adsl; no, non è cambiato nulla in riguardo, almeno che mi ricordi

non è che nella versione vecchia c'è un bug che li filtra