[Thread Ufficiale] Router NETGEAR DGN3500 [LEGGERE IL PRIMO POST!!!!]

[offbeatdave]

A few posts ago, I noted how 9.0.8 had made my wired connection better.

It has also made my SNR Margin more stable.

On older versions, when my line's target SNR Margin was 6db it would move up and down between 5.1dB and 5.7dB. With 9.0.8 it is generally staying at 6.0db. I haven't knocked it down manually yet to my optimum 3dB because I have just had the target SNR margin reset by my ISP after it crept up to 12dB with previous versions.

Also, it's pinging lower from the wired PC too. This is my latest result, even though I was streaming BBC HD TV wirelessly via a WDTV Live box.



9.0.8 is brilliant!

It may all be a coincidence, but thank you again.

[alfonsor]

hi offbeatdave, I really should like to say that yours are the results of the many efforts I put in making amod, but I think the truth is your line is better these days.

Many things changed in amod 9.0.8, there are some memory and net sysctl adjustment at the boot, f.e. it sets a greater limit to the memory reserved for kernel operations and it tries to frees unused buffers in a more aggressive way (I did it when I was trying to have a more stable samba streaming, believing it was a memory problem to crash the USB while at the end changing the PSU of the USB HUB with a more powerful one made the real difference).

I can't exclude that some of those tweaks may have some impact to your connection, but in the same way maybe your neighbors went skying and so your line is better

[alfonsor]

Originariamente inviato da zortec

In effetti nella documentazione è indicato di configurare CONFIG_NF_CONNTRACK come modulo come minimo (at least, has support for), ma credo non sia necessario configurarlo così. Non capisco che differenza possa fare all'applicativo se è incluso come modulo piuttosto che direttamente nel kernel.
Come dici tu, potrebbe sfasciare tutto, quindi credo sia meglio non toccarlo!

allora un aggiornamento: se mi impegno dopo un cinque sei di usi dell'utility di recupero a fare andare il kernel con tutte le modifiche, non solo conntrack manco funziona ancora pur avendo tutto quello che mai potrebbe desiderare, ma il dgn va lento, qualcosa occupa il 100% delle risorse e scalda come un fornetto; il bello è che tutto funziona, ma andare di telnet è praticamente impossibile

mi sa tanto che con il kernel 2.6.20, nonostante parlino di minimo 18, qualcosa non va molto nel meccanismo o forse ci vuole un hw migliore assai per avere quel meccanismo di eventi? non lo so

di certo ho deciso mi dispiace che non vale la pena, anche perché in /proc/net le connessioni le hai più o meno e diverse cose che vorresti fare si possono fare in altra maniera

il meccanismo dei conntrack tools non mi dispiaceva ma richiede troppo lavoro per un router, cioé per un apparecchio in cui devi reflashare e se non riesci a fare il boot, perché se qualcosa va male in rcS lampeggia rosso e si blocca, devi recuperare...

[zortec]

Originariamente inviato da alfonsor

[cut]
il meccanismo dei conntrack tools non mi dispiaceva ma richiede troppo lavoro per un router, cioé per un apparecchio in cui devi reflashare e se non riesci a fare il boot, perché se qualcosa va male in rcS lampeggia rosso e si blocca, devi recuperare...

Alfonsor, non volevo farti diventar matto per una cosa che era solo un interesse mio.. hai dovuto addirittura utilizzare il tool di recupero!
Grazie molte per il lavoro che hai dovuto fare!
Non credevo che il sistema ad eventi di conntrack facesse sedere così il processore: probabilmente come dici tu c'è qualche incompatibilità con la versione del kernel.
A questo punto credo che la soluzione per me sia utilizzare proc/net/conntrack_ip, scrivere un daemon che definisca un periodo di intervallo tale per cui non occupi troppo la cpu e perda il minor numero di connessioni.
Siccome ne sai più di me, secondo te questo metodo può andar bene o ci sono altre possibilità di fare la stessa cosa?
Grazie ancora!

[user43]

Ohila di nuovo

Frugavo nelle statistiche della mia linea, è possibile che al variare del tempo fluttui solo il noise margin in downstream, mentre invece la connection speed in down rimanga precisamente fissa?

[alfonsor]

questo è un argomento interessante perché non mi pare che ci sia un meccanismo di SRA (Seamless Rate Adaptation) nel driver adsl del chipset infineon, né che esista nei pochi sorgenti disponibili la possibilità di variare automaticamente il download in funzione del target snr

quindi, la mia risposta ignorante è che non è previsto, ma mi potrei molto facilmente sbagliare

[alfonsor]

Originariamente inviato da zortec

Alfonsor, non volevo farti diventar matto per una cosa che era solo un interesse mio.. hai dovuto addirittura utilizzare il tool di recupero!
Grazie molte per il lavoro che hai dovuto fare!
Non credevo che il sistema ad eventi di conntrack facesse sedere così il processore: probabilmente come dici tu c'è qualche incompatibilità con la versione del kernel.
A questo punto credo che la soluzione per me sia utilizzare proc/net/conntrack_ip, scrivere un daemon che definisca un periodo di intervallo tale per cui non occupi troppo la cpu e perda il minor numero di connessioni.
Siccome ne sai più di me, secondo te questo metodo può andar bene o ci sono altre possibilità di fare la stessa cosa?
Grazie ancora!

molto probabilmente non sono stato capace di adattare il kernel al meccanismo o non ho capito bene i driver da inserire però l'effetto è quello; per quanto riguarda il repristino è oramai una consuetudine quando vado a toccare il kernel in maniera non banale, meno male che è un'operazione abbastanza banale

per quanto riguarda tenere sott'occhio le connessioni c'è sempre tcpdump o anche ngrep, che ho compilato da tempo e mai messo, perché alla fine non puoi mettere tutto in uno spazio ristretto, devo fare un file da montare come modfs, in modo tale che se si vuole si possono usare

comunque c'è iptraf-ng che magari ti può bastare

[random566]

Originariamente inviato da alfonsor

questo è un argomento interessante perché non mi pare che ci sia un meccanismo di SRA (Seamless Rate Adaptation) nel driver adsl del chipset infineon, né che esista nei pochi sorgenti disponibili la possibilità di variare automaticamente il download in funzione del target snr

quindi, la mia risposta ignorante è che non è previsto, ma mi potrei molto facilmente sbagliare

secondo me è dovuto al fatto che nessun provider italiano imposta i propri dslam per utilizzare SRA, quindi anche abilitandolo lato router non succede nulla.
che io sappia, questo sistema viene utilizzato in inghilterra, ma dai vari forum sull'argomento sembra che non tutti ne siano pienamente soddisfatti.
probabilmente una delle motivazioni del mancato utilizzo del SRA è quello di evitare richieste di assistenza su linee problematiche, poichè lo scendere del downstream rate sotto un determinato valore in determinati periodi darebbe all'utente una valida motivazione per protestare.
forse per i gestori è meglio gestire le richieste di assistenza per frequenti disconnessioni.

[Hernia]

Tiscali mette in atto una sorta di abbassamento della portante di collegamento sulle ADSL 20MB, in particolari condizioni scatta il profilo a 16MB, da ignorante non saprei se si tratta di SRA, l'unica cosa che l'utente può fare e contattare il servizio tecnico e farsi rialzare la portante a 20MB.

[alfonsor]

Originariamente inviato da random566

secondo me è dovuto al fatto che nessun provider italiano imposta i propri dslam per utilizzare SRA, quindi anche abilitandolo lato router non succede nulla.
che io sappia, questo sistema viene utilizzato in inghilterra, ma dai vari forum sull'argomento sembra che non tutti ne siano pienamente soddisfatti.
probabilmente una delle motivazioni del mancato utilizzo del SRA è quello di evitare richieste di assistenza su linee problematiche, poichè lo scendere del downstream rate sotto un determinato valore in determinati periodi darebbe all'utente una valida motivazione per protestare.
forse per i gestori è meglio gestire le richieste di assistenza per frequenti disconnessioni.

con il dslam al quale mi connetto, invece, se sono con modem con un chipset broadcom, sul quale posso impostare l'opzione SRA, la velocità in download varia con il variare della SNR

come giustamente fai notare, non so se sia una cosa buona o cattiva, anche perché se la SNR diventa troppo bassa, anche in quel caso la linea viene sganciata, ovvero non è che sia la panacea; magari per linee davvero orrende, dove ci sono variazioni di SNR enormi da un momento all'altro, con questo si riesce a stabilizzare la linea quando serve, anche se fortunatamente non essendomi mai trovato in quelle condizioni non posso testimoniarlo direttamente

[PuNkEtTaRo]

Finalmente ho avuto modo di testare il firmware di alfonsor.
Che dire, funziona veramente bene e, così di primo acchito, tutto mi sembra più fluido.
Ho giusto qualche domanda:
- Perché hai lasciato sia il menu Firewall Rules che Port Forwarding? Il secondo non fa quasi tutto quello che si può fare dal primo?
- Non riesci ad inserire da qualche parte una form per specificare l'ssidn? A me non pesa affatto aprire telnet e dare 2 comandi, ma per qualcuno potrebbe essere più semplice farlo con il mouse.
Per il resto mi sembra tutto estremamente fluido e veloce.
Grazie ancora per il tuo contributo!

[random566]

Originariamente inviato da alfonsor

... non so se sia una cosa buona o cattiva, anche perché se la SNR diventa troppo bassa, anche in quel caso la linea viene sganciata, ovvero non è che sia la panacea;

però non credo che questo comportamento che descrivi sia da definire SRA.
le prime adsl erano a profilo fisso, cioè si agganciavano esattamente alla portante prevista dal profilo e nel caso che il margine di rumore non fosse sufficiente per la velocità prevista, l'aggancio non avveniva per niente.
invece attualmente quasi tutte le adsl italiane sono "rate adaptive" (non "seamless rate adaptive" o SRA), in pratica la velocità non è fissa, ma viene negoziata in modo da mantenere il margine di rumore uguale al target previsto dal profilo.
se dopo il training il margine di rumore varia, la velocità della portante rimane la stessa fino a che il margine di rumore rimane sufficiente per mantenere la portante agganciata.
pertanto se varia in aumento non succede niente, mentre se scende sotto il minimo necessario per l'aggancio o ci sono troppi errori ber, avviene una disconnessione e viene negoziata una velocità della portante adeguata per il nuovo valore del margine di rumore.
ai fini di questo comportamento non cambia niente se lato modem si imposta o meno il parametro SRA.
invece, sulle linee SRA usate in inghilterra, la variazione della portante, sia un aumento che in diminuzione, in base al margine di rumore della linea, avviene senza che si verifichi alcuna disconnessione.
in questo caso impostare SRA lato modem serve per attivare o escludere questo comportamento, disattivando SRA si comportano come le linee italiane.

[Hernia]

Originariamente inviato da PuNkEtTaRo

Ho giusto qualche domanda:
- Perché hai lasciato sia il menu Firewall Rules che Port Forwarding? Il secondo non fa quasi tutto quello che si può fare dal primo?
- Non riesci ad inserire da qualche parte una form per specificare l'ssidn? A me non pesa affatto aprire telnet e dare 2 comandi, ma per qualcuno potrebbe essere più semplice farlo con il mouse.
Per il resto mi sembra tutto estremamente fluido e veloce.
Grazie ancora per il tuo contributo!

Mi Piace !

[alfonsor]

Originariamente inviato da random566

però non credo che questo comportamento che descrivi sia da definire SRA.
le prime adsl erano a profilo fisso, cioè si agganciavano esattamente alla portante prevista dal profilo e nel caso che il margine di rumore non fosse sufficiente per la velocità prevista, l'aggancio non avveniva per niente.
invece attualmente quasi tutte le adsl italiane sono "rate adaptive" (non "seamless rate adaptive" o SRA), in pratica la velocità non è fissa, ma viene negoziata in modo da mantenere il margine di rumore uguale al target previsto dal profilo.
se dopo il training il margine di rumore varia, la velocità della portante rimane la stessa fino a che il margine di rumore rimane sufficiente per mantenere la portante agganciata.
pertanto se varia in aumento non succede niente, mentre se scende sotto il minimo necessario per l'aggancio o ci sono troppi errori ber, avviene una disconnessione e viene negoziata una velocità della portante adeguata per il nuovo valore del margine di rumore.
ai fini di questo comportamento non cambia niente se lato modem si imposta o meno il parametro SRA.
invece, sulle linee SRA usate in inghilterra, la variazione della portante, sia un aumento che in diminuzione, in base al margine di rumore della linea, avviene senza che si verifichi alcuna disconnessione.
in questo caso impostare SRA lato modem serve per attivare o escludere questo comportamento, disattivando SRA si comportano come le linee italiane.

guarda, se hai un dg834v4 puoi provare all'istante che anche qui da noi, almeno con il mio dslam, la velocità di download varia in funzione della SNR, in maniera molto limitata ovviamente, ma varia, senza disconnessioni

anche sul DGN3500 esiste un meccanismo per rinegoziare automaticamente la connessione al variare della SNR, ma non ho mai studiato bene come implementarlo perché mi sembra inutile e dannoso fare cadere la linea automaticamente, se la SNR cala

[alfonsor]

Originariamente inviato da zortec

Alfonsor, non volevo farti diventar matto per una cosa che era solo un interesse mio.. hai dovuto addirittura utilizzare il tool di recupero!
Grazie molte per il lavoro che hai dovuto fare!
Non credevo che il sistema ad eventi di conntrack facesse sedere così il processore: probabilmente come dici tu c'è qualche incompatibilità con la versione del kernel.
A questo punto credo che la soluzione per me sia utilizzare proc/net/conntrack_ip, scrivere un daemon che definisca un periodo di intervallo tale per cui non occupi troppo la cpu e perda il minor numero di connessioni.
Siccome ne sai più di me, secondo te questo metodo può andar bene o ci sono altre possibilità di fare la stessa cosa?
Grazie ancora!

io mo ti meno :PPP

ora sono riuscito a fare funzionare conntrack facendo uno stravolgimento del kernel e dello script del boot, ma... Non mi funziona più la USB

mannaggia la peppina che fa il caffè con la cioccolata

[user43]

Originariamente inviato da alfonsor

guarda, se hai un dg834v4 puoi provare all'istante che anche qui da noi, almeno con il mio dslam, la velocità di download varia in funzione della SNR, in maniera molto limitata ovviamente, ma varia, senza disconnessioni

Come esperienza personale col 384 mai una disconnessione... Avevo 'upgradato' nella erronea convinzione di migliorare la situazione col vicinato wifi, e confidando nel nome Netgear. Ma col 3500, in realtà, la situazio linea/wifi non l'ho stabilizzata fino all'arrivo di amod.

Ora come ora mi vine voglia di riesumare il 384 e andare giu a tirare un colpo di piccone nel 3500

[zortec]

Originariamente inviato da alfonsor

io mo ti meno :PPP

ora sono riuscito a fare funzionare conntrack facendo uno stravolgimento del kernel e dello script del boot, ma... Non mi funziona più la USB

mannaggia la peppina che fa il caffè con la cioccolata

Te l'avevo detto di lasciar stare...
Comunque con i miei lughi tempi, sto iniziando a scrivere il toll fa il polling da /proc/net.

ciao

[alfonsor]

Originariamente inviato da user43

Come esperienza personale col 384 mai una disconnessione... Avevo 'upgradato' nella erronea convinzione di migliorare la situazione col vicinato wifi, e confidando nel nome Netgear. Ma col 3500, in realtà, la situazio linea/wifi non l'ho stabilizzata fino all'arrivo di amod.

Ora come ora mi vine voglia di riesumare il 384 e andare giu a tirare un colpo di piccone nel 3500

dipende da che dslam hai; con il dg834 non posso scendere di SNR e quindi salire di download altrimenti gli errori diventano più dei pacchetti ricevuti senza errori, mentre con il dgn3500 posso osare quasi fino a meno di 2 di SNR senza grandi problemi

chiaramente parlando del lato modem, per il lato router il dgn3500 è ovviamente troppo più moderno per qualsiasi confronto

[alfonsor]

Originariamente inviato da zortec

Te l'avevo detto di lasciar stare...
Comunque con i miei lughi tempi, sto iniziando a scrivere il toll fa il polling da /proc/net.

ciao

eccolo qua

http://alfie.altervista.org/amod/dow....9_RC6.img.zip

prima di lanciare conntrack devi inserire il suo modulo, che non caricato automaticamente, come tutti i moduli che non sono strettamente necessari, ovvero devi dare
modprobe nf_conntrack_netlink
e quindi puoi usare conntrack
anche conntrackd è incluso, il suo uso è limitato a fare statistiche, non lo ho manco provato perché ora lo fai tu ! :P

[alfonsor]

Originariamente inviato da PuNkEtTaRo

- Perché hai lasciato sia il menu Firewall Rules che Port Forwarding? Il secondo non fa quasi tutto quello che si può fare dal primo?

Sono entrambi presenti nel firmware Nord Americano. Il primo serve a limitare l'accesso ad un servizio esterno o a limitare un servizio interno a determinati ip o in determinate ore. Con il secondo non puoi, per dire, limitare che qualcuno si connetta ad un server nelle ore di lavoro, ma solo fare in reindirizzamento delle porte.

Originariamente inviato da PuNkEtTaRo

- Non riesci ad inserire da qualche parte una form per specificare l'ssidn? A me non pesa affatto aprire telnet e dare 2 comandi, ma per qualcuno potrebbe essere più semplice farlo con il mouse.

Mahhhh, prima di tutto non saprei dove metterlo. Toccare la pagina wireless originale è un disastro per svariate ragioni. Secondo, deve essere proprio una volontà farlo ed inoltre amod non è proprio un firmware fool proof, ma molte cose sono da fare in telnet in linux, così la maggior parte degli utenti impara pure che cosa è una shell, altro che "ecco le mie statistiche, che ne dite?" :P