FIRMWARE CUSTOM NETGEAR DG834 SERIES -- CHIPSET BROADCOM -- (v4/GT/PN/N)

[cionci]

Originariamente inviato da schofield

si...se gli do applica si riallinea tranquillamente...anche se riavvio il router dopo va subito...

Che si riallineasse era fuori dubbio, ma si riattiva la sessione PPP ?

[cionci]

Lo script attualmente è questo:

#!/bin/sh

COUNTER=0
SLEEP_SECONDS=30
PING_IP=192.168.100.1


#get SNR Retrain Limit value
RETRAIN_SNR=`nvram get adsl_retrain_snr | sed 's/name=//'`

if [ ${#RETRAIN_SNR} = 0 ]; then
   #value not available, first time running this script set the value to 8
   nvram set adsl_retrain_snr=8
fi

PREVIOUS_PING=0

#infinite loop
while [ 1 ]; do
  
   MUST_RETRAIN=0

   #get SNR Margin value
   SNR=`adslctl info --show | grep SNR | sed 's/[^0-9]//g' | sed 's/[0-9][0-9][0-9][0-9]$//'`   
   
   if [ ${#SNR} = 0 ]; then
      #SNR Margin not available, maybe router is training line
      sleep $SLEEP_SECONDS
      PREVIOUS_PING=0
      continue
   fi

   #ping an address to check network connection
   PING_RESULT=`ping -c 1 $PING_IP 2>&1 1>/dev/null`
   if [ ${#PING_RESULT} != 0 ]; then
      if [ $PREVIOUS_PING -eq 0 ]; then
         PREVIOUS_PING=1
      else
         MUST_RETRAIN=1
         PREVIOUS_PING=0
      fi
   else
      PREVIOUS_PING=0      
   fi

   #get SNR Retrain Limit value
   RETRAIN_SNR=`nvram get adsl_retrain_snr | sed 's/name=//'`

   if [ $SNR -lt $RETRAIN_SNR ]; then
      MUST_RETRAIN=1   
   fi

   if [ $MUST_RETRAIN -eq 1 ]; then
      #delete log after 10 retrain
      if [ $COUNTER -eq 10 ]; then
         rm /tmp/retrain.log
         COUNTER=0
      fi

      let COUNTER++

      #retrain line and write to /tmp/retrain.log SNR value
      uptime >> /tmp/retrain.log
      echo "SNR Margin value is $SNR dB and limit is $RETRAIN_SNR...training line" >> /tmp/retrain.log

      ADSL_SNR=`nvram get adsl_snr | sed 's/name=//'`
      if [ ${#ADSL_SNR} = 0 ]; then
         #value is not set, setting at default
         ADSL_SNR="100"
      fi
      adslctl configure --snr $ADSL_SNR
   fi

   sleep $SLEEP_SECONDS

done

Dove è scritto:

PING_IP=192.168.100.1

devi mettere un indirizzo ip pingabile dalla tua connessione, meglio il più vicino possibile.
Per la mia connessione Alice il primo indirizzo ip pingabile è appunto 192.168.100.1 (è l'interfaccia interna del NAS di Telecom). Per altre connessioni potresti provare a pingare il default gateway che vedi appunto nelle informazioni della sessione PPPoE (nel tuo caso).

Le istruzioni per installare lo script sono queste: http://www.hwupgrade.it/forum/showpo...postcount=4044
Ovviamente i comandi li devi dare collegandoti in telnet all'indirizzo ip del router.
In un futuro credo che scriverò anche le istruzioni per aggiungerlo direttamente al firmware con lo script del dgteam, magari con una paginetta per le impostazioni e lo stato.

A me sta funzionando in maniera egregia.
Ecco il log:

13:04:21 up 1 day, 5:13, load average: 0.01, 0.02, 0.00
SNR Margin value is 7 dB and limit is 9...training line
13:25:45 up 1 day, 5:34, load average: 0.05, 0.08, 0.01
SNR Margin value is 8 dB and limit is 9...training line
13:29:38 up 1 day, 5:38, load average: 0.00, 0.02, 0.00
SNR Margin value is 7 dB and limit is 9...training line
16:48:59 up 1 day, 8:57, load average: 0.02, 0.02, 0.00
SNR Margin value is 8 dB and limit is 9...training line
18:08:44 up 1 day, 10:17, load average: 0.01, 0.00, 0.00
SNR Margin value is 7 dB and limit is 9...training line
18:19:00 up 1 day, 10:27, load average: 0.00, 0.00, 0.00
SNR Margin value is 8 dB and limit is 9...training line
18:53:49 up 1 day, 11:02, load average: 0.00, 0.01, 0.00
SNR Margin value is 8 dB and limit is 9...training line


Attualmente lo script riallinea se trova un SNR Margin in download più basso di 8 dB (da 7.9 in giù).
Puoi modificare questo valore con l'istruzione:

nvram set adsl_retrain_snr=7

E riallinearà da 6.9 dB in giù.

Se nel log trovi una linea tipo questa:

SNR Margin value is 12 dB and limit is 8...training line

Ha riallineato nonostante l'SNR Margin a 12 perché la connessione PPP era morta

[asterixb]

Bannato dal forum del dgteam solo xkè ho detto ke il firmware ha dei bug e i creatori non vogliono sentire ragioni...... questo vi fà capire tutto....
Spero escano subito nuove strade...

inizio OT
Mi stai sicuramente leggendo quì, non hai fatto una grande figura bannandomi dal tuo forum...
Fine OT

[FreeMan]

si era già detto che non ci interessa portare qui questa polemica. Quindi, evitiamo di farcelo ripetere all'infinito.

>bYeZ<

[asterixb]

si si ok

[cionci]

Si può almeno sapere di quale bug stai parlando ?

[asterixb]

da pagina 197

http://www.hwupgrade.it/forum/showth...5#post27400935

e poi gli altri problemi ke hanno avuto altri utenti e io fortunatamente no...

[full64]

Up. C'è un anima gentile che mi può dare una mano?

[axelv]

Ciao a tutti, avevo anche aperto un nuovo post ma è meglio se lo scrivo qua. Se i mod vogliono cancellarlo è meglio.

Ogni tanto mi succede questa cosa..

Qualche giorno fa il pc non aveva la connessione ad internet. Allora sono andato nella pagina del router (Netgear DG834GT)e ho visto che le spie erano tutte correttamente accese. Anche nell'interfaccia del router c'era la portante ma mancava "la connessione". In pratica avevo questo:



Ho provato a riavviare tramite software ma niente, non negoziava. Solo staccando e riattaccando la corrente ha funzionato. Anche l'altra volta....

Stanotte stessa cosa. Sono anche fuori casa e meno male che stamani si è ricollegato.

Ecco il registro

Sat, 2009-07-25 12:56:53 - LCP down.
Sat, 2009-07-25 12:57:00 - Initialize LCP.
Sat, 2009-07-25 13:01:32 - LCP is allowed to come up.
Sat, 2009-07-25 13:01:32 - PAP authentication success
Sat, 2009-07-25 13:01:41 - <DDNS>Update OK: good
Mon, 2009-07-27 06:05:10 - Send out NTP request to time-g.netgear.com
Mon, 2009-07-27 06:06:12 - Send out NTP request to time-h.netgear.com
Mon, 2009-07-27 06:07:47 - Send out NTP request to time-g.netgear.com
Mon, 2009-07-27 06:10:25 - Send out NTP request to time-h.netgear.com
Mon, 2009-07-27 06:15:11 - Send out NTP request to time-g.netgear.com
Mon, 2009-07-27 06:24:14 - Send out NTP request to time-h.netgear.com
Mon, 2009-07-27 06:41:48 - Send out NTP request to time-g.netgear.com
Mon, 2009-07-27 07:16:26 - Send out NTP request to time-h.netgear.com
Mon, 2009-07-27 08:25:13 - Send out NTP request to time-g.netgear.com
Mon, 2009-07-27 10:42:15 - Send out NTP request to time-h.netgear.com
Mon, 2009-07-27 15:15:49 - Send out NTP request to time-g.netgear.com
Tue, 2009-07-28 00:22:28 - Send out NTP request to time-h.netgear.com
Tue, 2009-07-28 18:35:14 - Send out NTP request to time-g.netgear.com
Tue, 2009-07-28 18:41:02 - LCP down.
Tue, 2009-07-28 18:41:10 - Initialize LCP.
Tue, 2009-07-28 18:41:10 - LCP is allowed to come up.
Tue, 2009-07-28 18:41:10 - PAP authentication success
Tue, 2009-07-28 18:41:19 - <DDNS>Update OK: good
Tue, 2009-07-28 22:05:15 - LCP down.
Tue, 2009-07-28 22:05:23 - Initialize LCP.
Tue, 2009-07-28 22:15:26 - Initialize LCP.
Tue, 2009-07-28 22:25:30 - Initialize LCP.
Tue, 2009-07-28 22:35:34 - Initialize LCP.
Tue, 2009-07-28 22:45:38 - Initialize LCP.
Tue, 2009-07-28 22:54:41 - Initialize LCP.
Tue, 2009-07-28 23:04:45 - Initialize LCP.
Tue, 2009-07-28 23:14:48 - Initialize LCP.
Tue, 2009-07-28 23:24:52 - Initialize LCP.
Tue, 2009-07-28 23:34:56 - Initialize LCP.
Tue, 2009-07-28 23:45:00 - Initialize LCP.
Tue, 2009-07-28 23:55:03 - Initialize LCP.
Wed, 2009-07-29 00:05:07 - Initialize LCP.
Wed, 2009-07-29 00:15:11 - Initialize LCP.
Wed, 2009-07-29 00:25:14 - Initialize LCP.
Wed, 2009-07-29 00:35:18 - Initialize LCP.
Wed, 2009-07-29 00:45:22 - Initialize LCP.
Wed, 2009-07-29 00:55:26 - Initialize LCP.
Wed, 2009-07-29 01:05:29 - Initialize LCP.
Wed, 2009-07-29 01:15:33 - Initialize LCP.
Wed, 2009-07-29 01:25:37 - Initialize LCP.
Wed, 2009-07-29 01:34:40 - Initialize LCP.
Wed, 2009-07-29 01:44:44 - Initialize LCP.
Wed, 2009-07-29 01:54:48 - Initialize LCP.
Wed, 2009-07-29 02:04:51 - Initialize LCP.
Wed, 2009-07-29 02:14:55 - Initialize LCP.
Wed, 2009-07-29 02:24:59 - Initialize LCP.
Wed, 2009-07-29 02:35:03 - Initialize LCP.
Wed, 2009-07-29 02:45:06 - Initialize LCP.
Wed, 2009-07-29 02:55:10 - Initialize LCP.
Wed, 2009-07-29 03:05:14 - Initialize LCP.
Wed, 2009-07-29 03:15:18 - Initialize LCP.
Wed, 2009-07-29 03:25:21 - Initialize LCP.
Wed, 2009-07-29 03:35:25 - Initialize LCP.
Wed, 2009-07-29 03:45:29 - Initialize LCP.
Wed, 2009-07-29 03:55:33 - Initialize LCP.
Wed, 2009-07-29 04:05:36 - Initialize LCP.
Wed, 2009-07-29 04:15:40 - Initialize LCP.
Wed, 2009-07-29 04:24:43 - Initialize LCP.
Wed, 2009-07-29 04:34:47 - Initialize LCP.
Wed, 2009-07-29 04:44:51 - Initialize LCP.
Wed, 2009-07-29 04:54:55 - Initialize LCP.
Wed, 2009-07-29 05:04:58 - Initialize LCP.
Wed, 2009-07-29 05:15:02 - Initialize LCP.
Wed, 2009-07-29 05:25:06 - Initialize LCP.
Wed, 2009-07-29 05:35:10 - Initialize LCP.
Wed, 2009-07-29 05:45:13 - Initialize LCP.
Wed, 2009-07-29 05:55:17 - Initialize LCP.
Wed, 2009-07-29 06:05:21 - Initialize LCP.
Wed, 2009-07-29 06:15:25 - Initialize LCP.
Wed, 2009-07-29 06:25:28 - Initialize LCP.
Wed, 2009-07-29 06:35:32 - Initialize LCP.
Wed, 2009-07-29 06:45:36 - Initialize LCP.
Wed, 2009-07-29 06:55:39 - Initialize LCP.
Wed, 2009-07-29 07:03:43 - LCP is allowed to come up.
Wed, 2009-07-29 07:03:43 - PAP authentication success
Wed, 2009-07-29 07:03:52 - <DDNS>Update OK: good

Secondo voi da cosa dipende?? Ho il firmware 743....

[slime]

@quelli che hanno il problema di LCP Inizialize: avete Alice come connessione? Se è così il problema è TI. Ogni tanto capita anche a me, molto di rado ultimamente. La maggiorparte delle volte nei weekend. Sembra che non venga assegnato un indirizzo IP dal server TI o che ci sia una caduta del server stesso. Una volta ho chiamato l'assistenza e mi hanno confermato che il sincronismo adsl c'era ma che era impossibile fornire un indirizzo ip... Forse stanne esaurendo le risorse rispetto al numero di abbonati. Speriamo bene.

[axelv]

Si, ho Telecom! E quindi non ci si può fare niente????

[littlemau]

Ho sperimentato pure io il blocco (dopo 2000 ore di stabilità). Ho anch'io alice ma dubito sia un problema di TI. Pure a me non ha funzionato il riavvio da webGUI mentre tutto si è normalizzato con disconnessione da rete elettrica. Se fosse un problema di TI non dovrebbero essere entrambe efficaci (o inefficaci)?

[FreeMan]

Anche me è sempre successo (indipendentemente dal FW direi).. sempre ritenuto la colpa di TI.. va detto che cmq basta aspettare si ripiglia, infatti sto costantemente up senza doverlo mai resettare, se non ci fosse stato il prob del nuovo client wifi (Il nuovo cell), bug noto, ora starei sulle 10.000 ore di up ho giusto battuto il mio precedente record (vedi sign) di uptime



sempre con il 743

>bYeZ<

[slime]

In genere la colpa è di TI, il fatto di aver tolto alimentazione e rimessa e il ritorno della connessione può essere un caso. Io parlo di portante adsl che rimane e caduta solo della connessione. In questo caso il riavvio anche fisico del router la connessione non ritorna. Fino a quando il server TI non rilascia l'indirizzo IP nulla da fare. Da me dopo un paio di weekend con la connessione in questo stato le cose sembrano normalizzate.

P.S. Cosa sperimentata anche con il WAG200G della Linksys, quindi il problema è sulla linea.

[full64]

Originariamente inviato da full64

Ciao a tutti spero che qualcuno possa darmi una mano.
Ho da poco aggiornato il firmw. con quello del DGTeam 1.01.32 Rev.0743 che funziona bene.Quando lo collego in wireless dopo 3/4 giorni si freeza e pianta tutto.
Ora capite che quando sono a casa,anche se è antipatico, riavvio tutto e buona notte. Ma siccome spesso sono fuori e gestisco il mio p2p tramite interfaccia web.....beh avete capito tutto.
Cosa potrebbe essere?

Ecco perchè mi piaciono i forum....quando hai un problema non ti fila mai nessuno.
Cmq aggiorno lo stesso la situazione. E' una settimana che ho collegato il router con cavo ethernet e non più in wireless. Ora funziona problema risolto!!!!!

[FreeMan]

Originariamente inviato da full64

Ecco perchè mi piaciono i forum....quando hai un problema non ti fila mai nessuno.

simpatico.. e perchè ci posti allora? se hai risorse migliori usale

cmq se nessuno ha detto nulla i motivi possono essere vari, dall'argomento ciclico o cmq già trattato (fatta ricerca nel 3d?) oppure nessuno aveva qualcosa da dirti anche perchè mancano delle info come l'utilizzo che fai del pc in wifi, che scheda usi nel client ecc.. tutte cose che aiutano perchè come puoi vedere nel mio shot fatto con il 743 a me il wifi sta up quanto la lan.. cosa che accadeva anche con il .32 liscio..

certo che poi leggere certe uscite non renderà gli utenti + disposti di prima nel risponderti

>bYeZ<

[cionci]

Originariamente inviato da slime

@quelli che hanno il problema di LCP Inizialize: avete Alice come connessione? Se è così il problema è TI. Ogni tanto capita anche a me, molto di rado ultimamente. La maggiorparte delle volte nei weekend. Sembra che non venga assegnato un indirizzo IP dal server TI o che ci sia una caduta del server stesso. Una volta ho chiamato l'assistenza e mi hanno confermato che il sincronismo adsl c'era ma che era impossibile fornire un indirizzo ip... Forse stanne esaurendo le risorse rispetto al numero di abbonati. Speriamo bene.

Imho non è un problema di Telecom Italia, ma è un problema della sessione PPP che cade per il SNRM troppo basso e cerca di essere ripristina quando ci sono ancora troppi errori di connessione. I router (ho lo stesso problema con tutti i router che ho provato) dovrebbero fare un retrain della linea se la connessione PPP cade per la quantità di errori, invece questo non viene fatto. Così il router cerca di ripristinare la sessione magari con 3-4 dB di SNRM e chiaramente non ci riesce entrando in uno stato che evidentemente non è previsto del sorgente del demone PPP o da chi lo gestisce.

La mia soluzione:
http://www.hwupgrade.it/forum/showpo...postcount=4159

[slime]

Originariamente inviato da cionci

Imho non è un problema di Telecom Italia, ma è un problema della sessione PPP che cade per il SNRM troppo basso e cerca di essere ripristina quando ci sono ancora troppi errori di connessione. I router (ho lo stesso problema con tutti i router che ho provato) dovrebbero fare un retrain della linea se la connessione PPP cade per la quantità di errori, invece questo non viene fatto. Così il router cerca di ripristinare la sessione magari con 3-4 dB di SNRM e chiaramente non ci riesce entrando in uno stato che evidentemente non è previsto del sorgente del demone PPP o da chi lo gestisce.

La mia soluzione:
http://www.hwupgrade.it/forum/showpo...postcount=4159

Se hai letto il mio post successivo ho anche spiegato che riallineando il router (sia da interfaccia web che fisicamente togliendo e mettendo alimentazione) la connessione non torna, si allinea solo la portante. Dopo intervalli irregolari (da 2 ore a max 4 finora mi è capitato) l'indirizzo IP viene rilasciato dal server e la connessione ritorna. Non so se possa dipendere dalla piastra sul dslam o da momenti di "vuoto" determinati da aggiornamenti dei sistemi TI. Inoltre nel momento in cui la connessione cade i valori della portante sono assolutamente buoni, infatti la portante rimane su. E' proprio una disconnessione dal server dhcp.

[cionci]

Ooops...questo è successo anche a me diverse volte e credo dipenda da Telecom (ha una specie di timeout dopo tot volte che la sessione PPP viene ristabilita). Mi succede appunto quando la sessione PPP cade molto spesso. Lo scopo del mio script è proprio di non farla terminare così spesso riallineando la portante nei momenti in cui SNRM cala molto.

[axelv]

Beh dai, allora vedo che il problema si presenta a diverse persone. Il fatto brutto è che non c'è soluzione. Non ho problema di snr, viaggio sempre sui 12/14.
La cosa però mi fa arrabbiare molto perchè su due volte che mi è successo è stato tutta la notte per riprendere l'ip!! Sono un pò arrabbiato...